-
Notifications
You must be signed in to change notification settings - Fork 3
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
Improve authentication and autorization #29
Comments
So I think we should used OAuth2 with the scopes instead of groups. https://oauth.net/2/scope/ I also think that public endpoints should need tokens. According to Katrina there will be no users, no adding add seems unnecessary, she says there will only be two different roles with different permissions or scopes. |
@git-ari, the auth implementation was standard Spring Security, that takes care of both authentication and authorization. Even with "only two different roles", there needs to be a standard way to manage authentication and authorization; this is provided as seen here and here. When you say "overengineered", what exactly do you mean. The only libraries included for auth was for token generation and validation. Is logging mandatory? I assumed the Regarding exceptions, I did ask if there was a way to use an exception with different messages. For example, token validation throws several different exceptions. defining a custom exception for every possible exception seems a bit much. Could we refactor the Swagger is working fine on my local machine. It even picks up the new endpoints (albeit without proper formatting). Of course, formatting can be worked on further. |
Regarding the token refresh time, I assume the concern is that the angular client is unable to make requests after the token has expired. If that it is the concern, there is a solution to extend the token expiry described here, that I propose we implement. |
I'm sorry, I noticed I made a mistake. I wanted to say that I believe public endpoints should NOT need tokens, or users. I have researched the subject a bit more, and it may not apply with us, you are right. I personally have worked in a company where they used OAuth2 for managing the "authorities" even within the application, but maybe that made more sense back then since they used microservices architecture. I personally liked it and I think we could use it still, that it wouldn't make the application worse, but I understand if we don't do it.
I mean for example all the
I believe its not up to us to define the messages that are presented on the front end. There should be different exceptions for different problems so that when we throw the exception back to the frontend it can look at its code and react differently to each. The message is there in the event someone just uses the API and it provides some extra information on what the problem was. In the way that it is implemented you can still define the message as you did but I think its not something that should be used often.
You can use the endpoints for the autentication, but you cant use the others because there is no space to put the token. If its configured correctly you can use it with the token. |
Topics:
Please feel free to enhance the discussion with new topic and new ideas.
The text was updated successfully, but these errors were encountered: