Fixes #17487 - support sessions for api calls #4045
Conversation
|
@tstrachota, thanks for your PR! By analyzing the history of the files in this pull request, we identified @bbuckingham, @domcleal and @dLobatog to be potential reviewers. |
|
@tstrachota, the Redmine ticket used is for a different project than the one associated with this GitHub repository. Please either:
This message was auto-generated by Foreman's prprocessor |
|
There were the following issues with the commit message:
If you don't have a ticket number, please create an issue in Redmine. More guidelines are available in Coding Standards or on the Foreman wiki. This message was auto-generated by Foreman's prprocessor |
| assert_equal users(:admin).id, session[:user] | ||
| end | ||
| end | ||
|
|
There was a problem hiding this comment.
Extra empty line detected at class body end.
|
@tstrachota, the Redmine ticket used is for a different project than the one associated with this GitHub repository. Please either:
This message was auto-generated by Foreman's prprocessor |
tstrachota
changed the title
theforeman-bot
added
Waiting on contributor
Needs re-review
Needs testing
and removed
Not yet reviewed
Waiting on contributor
labels
|
Rebased |
|
Sorry, please rebase again to ensure ee7d140 is included - the test suite isn't fully running currently. |
- authenticated api calls save user to session and set flag api_authenticated_session - sessions with such flag allow posting requests without CSRF token - api sessions exipre the same way as UI sessions - api sessions don't store any additional data to keep the requests stateless This way the standard UI requests as well as API requests authenticated with session created from UI remain protected against CSRF. At the same time applications using API (such as hammer) can benefit from using session authentication and avoid the need of storing two tokens (CSRF and _session_id).
theforeman-bot
added
Needs re-review
Needs testing
and removed
Waiting on contributor
labels
|
Rebased |
|
Merged, thank you for the nice addition @tstrachota. |
This way the standard UI requests as well as API requests authenticated with session created from UI remain protected against CSRF. At the same time applications using API (such as hammer) can benefit from using session authentication and avoid the need of storing two tokens (CSRF and _session_id).