Feature/api auth refactor - #610
Conversation
ebc89d2 to
2ad770b
Compare
santostiago
left a comment
santostiago
left a comment
There was a problem hiding this comment.
It all seems fine, but what is the goal?
What is the problem with the existing authorization header?
| module ClassMethods | ||
| def apply_includes(records, directives) | ||
| super.includes(:document_file, :required_operator_document) | ||
| result = super |
There was a problem hiding this comment.
This has nothing to do with the PR's goal, right?
There was a problem hiding this comment.
Yes, one of those methods was failing somewhere; that's why I added that safeguard everywhere.
|
@santostiago the goal is to eliminate high security issues and simplify things. I had an alternative: install doorkeeper or reimplement OAuth, as the current token system was not great (tokens not expiring, cannot be revoked, there should be short- and long-lived tokens, refresh tokens, the Angular app is an SPA - no server and it was keeping tokens in LocalStorage - bad practice). I decided that cookies as a standard for web-based applications are the safest and easiest choice. I'm currently using cookies for authorized download sessions, and with this I can remove download sessions and just keep this. |
2ad770b to
49cdb2e
Compare
2 participants
Add cookie-based auth to API. Frontend apps are using the same domain, and Angular app is SPA and cookies are the most secure way of storing user authentication.
JIRA: https://gfw.atlassian.net/browse/OPEN-389