-
Notifications
You must be signed in to change notification settings - Fork 98
Allow cookie for authentications #199
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
@mkunzmann, thanks for the enhancement. I am hoping to try this out before merging in ~ but wanted to mention that the changes you have provided look good. |
Allow usage of a cookie for authentication to the confluence API. This might be useful if the confluence instance is hidden behind some single- sign-on services. Signed-off-by: Michael Kunzmann <michael.kunzmann@gmx.net>
@mkunzmann, out of curiosity, do you use cookie authentication through a proxy/third-party configuration? From what I can tell, Atlassian has been removing their support for cookie-based authentication (promoting API keys instead). This makes me hesitate to add this feature into this extension for a short-lived authentication manner. However, if you have a use case where you are authenticating using other means, I would not mind going ahead and supporting passing session values in REST requests. On another note, I am wondering if it would be better to tweak all this to support configuring session cookies outside the context of just password management (i.e. remove the implication that |
@jdknight Thanks for your response and sorry for my late reply. I currently use this with cookies for a SiteMinder SSO solution that replaces the JIRA authentication for us. So setting the cookies allows a login, password and username are not required in this case. If there are use cases where setting both user/password and cookies the restriction can be removed. |
(template-like response) Changes in this pull request look to be in good state. Delays in other features in this project will result in this feature being delayed (see this comment for more details), so the expected window for this feature is planned around end-of-year (2019). Feel free to make additional changes/etc. to this pull request before the planned window. Critical changes may occur on master before this pull request is merged in -- while you are free to help synchronize features as conflicts are detected, I do mind help correcting conflicts myself when I have the opportunity to merge this change in. If you wish to review changes I may stack on this pull request set, feel free to indicate so. When the window to merge this in this pull requests occurs and changes are needed, I can stack on change and wait for your additional approval. Otherwise, I will assume I may stack changes (if needed) which is deemed best for this extension for a quicker integration into master. Labeling this pull request as "planned-end-of-year". A quick review of this pull request include the following:
|
The original implementation for user-provided cookies for REST sessions was only permitted when a user did not also provide password values as well. The following tweaks the flexibility of users providing cookie entries by allowing them to configure cookies whether or not authentication information is also configured. Signed-off-by: James Knight <james.d.knight@live.com>
Adding new cookie configuration information in a new "category" for advanced authentication capabilities. This is to help pull the cookie option out of the essential configuration section and also prepare for other prospect authentication changes coming to the extension. Signed-off-by: James Knight <james.d.knight@live.com>
Finally merged in -- sorry for the delay. Thanks for change. |
Allow usage of a cookie for authentication to the confluence API. This
might be useful if the confluence instance is hidden behind some single-
sign-on services.
Signed-off-by: Michael Kunzmann michael.kunzmann@gmx.net