tangara goh wrote:I would like to know if I can just bring in the role from my other class to User table instead of doing a Join here.
The author uses Integer id in all the POJO classes, so in my database, is it ok not to use Id for User table but UserId which differ from the Id in the POJO ?
Furthermore, I would like to know when a userId and passwords are stored inside the table for JWT authentication, the passwords do I need a encryption library to encrypt it before inserting into the db ?
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:one-to-many.
True.Stephan van Hulst wrote:
Tim Holloway wrote:one-to-many.
Many to many. A user can have many roles, and a role can be filled by many users.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Stephan van Hulst wrote:I can't suggest anything if I don't know what your application is supposed to do. Please tell us your functional requirements, and what you're stuck on.
Stephan van Hulst wrote:So you ARE implementing an identity provider. Then you can continue with the tutorial, as I mentioned in my first reply.
The type UserDetailsServiceImpl must implement the inherited abstract method UserDetailsService.loadUserById(String)
tangara goh wrote:But, how do I authenticate against a UserId and not UserName ?
I have been searching for a tutorial to implement loadUserById to no avail....
So far I have attempted to change the loadUserByName in the original code to use loadUserById but it is not being accepted ...
...
I hope someone can give me some hints how to have SpringBoot to recognise the new method in my interface ..cos doing an @override also doesn't help.
Stephan van Hulst wrote:You are sending user credentials over a GET request. NEVER send sensitive data over GET requests! GET payloads are not encrypted and will appear as plain text in a network analyzer.
You are doing absolutely nothing useful with the provided ID and password, as far as I can tell. Why do you need all those parameters anyway, if you're just grabbing the current User that Spring manages for you?
Why is the code full of print statements?
tangara goh wrote:It is hard to determine if one should use GET or POST since it is not indicated.
I thought since we are comparing something in the database it should be a GET. But, with a form added, it could be a POST except this one is without front-end.
Why do I need ID and password ? Because I would need to return a error message if it is invalid...
Are you saying I should you ResponseBody as parameter ?
Can't really tell what went wrong till the db is set up or is there any other way to tell the output ?
Why do I need ID and password ? Because I would need to return a error message if it is invalid...
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
tangara goh wrote:So, if I change it to a POST Request, the rest of the code is ok right?
Stephan van Hulst wrote:
Anyway, if you've already followed various Spring tutorials, I wouldn't suddenly jump back to Java EE. If you choose to continue with Spring, you aught to use Spring Security to handle your user authentication.
Stephan van Hulst wrote:Again, it all depends on your goals.
Who are your users? How are they going to access your application? Does your application provide a front-end, or only a web API? If your application provides a front-end, is it an SPA or does it consist of multiple pages?
tangara goh wrote:How are they going to access the app is not specified so I will opt for database access.
I am only required to do backends. No front end is involved.
tangara goh wrote:BTW, they have indicated result, roles and errorMessage as field
does it mean that I have to store the result like 200ok, 401 into the database which is quite a strange practice to me and the error Message as well which will only make sense if it is accompanied by DateTimeStamp but for this case it is not indicated.
Base on the first operation, does session management still needed ?
In any case, I have found out from all those ubiquitous tutorials and come out something like that :
Stephan van Hulst wrote:The assignment describes an identity provider, but with a pretty poor and insecure API.
Anyway, if you want to do exactly what the assignment says, you can, as long as you keep in mind that this is not how web services work in the real world.
Don't use the user field in your controller action. The user field is provided by Spring. If you're hacking your own authentication, you shouldn't use it.*
* In a real world application, you would rely on the user field provided by Spring, and not write your own authentication.
tangara goh wrote:I am using my own User class but extending Spring user class, does that mean that I just use Java coding to check the userId and password will do and pass in to SpringBoot's Authentication API
Another thing is I am stuck as to how do I test the end point using Postman ?
I am not sure which Authorisation I should use under post man Authorisation tab....
furthermore, the console did not print out that I am inside the end point....
Seems that my end point is not doing correctly...maybe I can't mix Java with Spring Authentication ?
Consider Paul's rocket mass heater. |