-
Notifications
You must be signed in to change notification settings - Fork 39
Add support for authentification and history #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
pirate
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work, thanks for contributing these features!
You should be able to accept most of the suggestions from the Github UI without having to commit manually, but make sure to double check that it works as expected after making the suggested changes.
|
I corrected the spelling issues, but I'm not sure that leaving cookie in a static file by default is a good idea @pirate |
|
@Fumesover then maybe use mktemp to avoid conflicts on multi user systems? |
|
@fbartels and how do we save the path ? |
|
yes, you would still need to have a config file in ~ which would have the path to the cookie. not really elegant indeed. btw. I did a checkout of your repo and for me the login fails. I setup a user with a less complex password, but even here it fails. the file ~/.codimd-key.conf is not created by running codimd-cli |
|
@fbartels using $HOME instead of ~ seems to correct it |
|
now that file is actually filled, but login still fails: |
|
Oh ! It's because you are using ldap @fbartels, my code only works for email login actually |
|
Yes, it is indeed an ldap backend. I did not expect that this will lead to different auth endpoints. Maybe there could be an automatic fallback? |
|
This is a 3rd party integration, I don't think integrating it as an automatic fallback is relevant |
|
I agree that leaving a cookie in a local file is less ideal than somewhere like a keychain, but I also don't think it's the end of the world, as it's a pattern used by other tools for sensitive keys. E.g. It's common to store AWS keys in As long as the permissions limit the cookie file to only the current user (I think we should add that to the bash script), I'm ok with it. |
|
yes, looking at the code again, a better option would be to have a dedicated "ldap" parameter and a dedicated auth function for it. since all the other stuff is just checking with the stored cookie if the session is still valid you could have multiple auth functions |
|
Now there is support for email & ldap and it will be easy to add other protocols Sorry @fbartels, I hadn't seen your PR, and I think making it modular as I did would be easier to maintain |
|
Having a text file somewhere in your filesystem is also exactly what browsers were doing for years. Today Firefox and Chrome store this in an SQLite database - still in your profile folder. No difference at all with regard to security. (Firefox: Profile directory |
|
Okay so actually the default is |
|
I would like to propose something like the XDG Base Directory Spec, in this case Base reason is, that I don't particularly like all that clutter in my home directory. |
|
Yeah, I'd be fine with either of |
|
So, now the default is |
No description provided.