I am going to have couple different features, for which user need to paid. then only the users will have access to that feature, or sat to that endpoint. what would be the best way to do such a thing?
I've researched, but couldn't find any example for that flow.
do i need to have a custom filter to verify if the user possessing this token has access to this feature or not for every request, since that is going to be a database call in filter.
or if any other service is offering this solution?
this is a theoretical question, need to understand the concept.
Related
I have never really done authentication yet. At this moment, I'm stuck and not really sure on what would be the best and most secure way to handle it.
To get an overview on what I'm working with:
For the backend/REST API I'm using Spring Boot and for the frontend NextJs.
Furthermore, Two types of users are needed, some who can either create, analyze or manage content (basically different roles) in our custom CMS. And on the other side, app users who are consuming this content (on a iOS app).
That's what I'm trying to achieve as a minimum requirement, but it would be even better if it would somehow be possible to manage only a list of specific content for a specific role (e.g. analyze). Like for example, only blog articles that are in this list.
I know it's a really broad question, but I would be happy with some general directions or links to resources that could guide me in a way.
I am not so much in need of code help here, more advice on how I should handle this scenario.
I have a REST API built, using Spring boot.
I also have a simple Hybrid app that I need to deploy to users within the company - and clients who "buy in" to the API access. The users can be anywhere in the world, which means I never know what domain they will be on.
I am told that using the header below is bad practice :
"Access-Control-Allow-Origin":"*"
Given that I know the only point of access with our API should be this frontend app, but that I never know where the user of that app will be, or what network they will be on, how should I do this?
Tagging spring community here, even though this is not a spring centric question. This is because I am actually using Spring, and I guess that community will have solved this problem before.
I believe that this question is not about CORS exactly.
"Access-Control-Allow-Origin":"*" is OK since you need your API to be accessible from anywhere.
Even if you know all the Origins you need to allow, you should not rely on Origin header sent from the client as one can send any header.
Authenticate your users and you'll know whether the user can access the API or not.
Thanks.
My app needs to support two types of users:
regular users , these are those who are subscribers (restaurants
that use my app for managing their business). For these users, I
have the out of box authentication (Laravel 5.1) set up. email and
password are the fields I authenticate on. I maintain information
about such users in my users table.
guests, these are people who
visit the restaurants above, register to earn loyalty points, check
their score, leave feedback, etc. I maintain information about such
users in my guests table. Authentication, in this case, is simple.
I just use a mobile_number to authenticate them into the app.
I get that I can implement guest's authentication in a subdomain of my app, with different Controllers and Views.
What I don't get is, how can I use the eloquent database driver with the two distinct models? I see that we specify the model eloquent would be using through config.auth.model. So, I'm assuming that we can only have one single model implementing authentication.
Is, what I trying to achieve, possible without implementing a custom driver?
Short answer: No.
You need a custom driver for this. But that shouldn't be too hard to implement, as you can easily get inspiration from/or extend the current EloquentUserProvider. You can also check out the answer to this other question:
Custom user authentication base on the response of an API call
The context is different than yours, but it may help getting a better grasp on the implementation approach (that is if you haven't done this before).
I'm currently working on a iphone/android project where the mobile talk ta java backend server through REST API calls.
The Java backend is done using Spring and its Authentication system (with a JSESSION ID token)
I'm not an expert in security but I can see that if not implemented correctly there could be quite a lot of issues.
One of my biggest concern would be user creation for example.
When the app creates a user it simply makes a POST request to (url.com/rest/create)
How can I avoid, server side, that a malicious user puts this url in a loop and create thousands of users ?
What are common best practices to secure API calls ?
Is the Spring Authentication token enough ?
Thank you!
It's not really possible to prevent a client from making many calls to your server. A malicious user can create a script or application firing requests to your server.
The solution is to authenticate and authorize the calls to the server. You give certain users (for example administrators) the privilege to create users. You trust those users to behave in a correct manner. You have your users authenticate before they call the APIs on your server. Then, on the server side your check who the user is and what he/she is allowed to do.
If you are still concerned about privileged users not behaving, you can assign quota to each user on the actions they are allowed to perform.
The hightech solution (with as much framework fuctions as possible) would be
first: have a created-by and created-date field at the entity you want to protect (I recommend to use Spring-Data-JPA Auditing for that).
second: create a custom spring method (or web) expression method that is able to check how many items the current user has created in the (for example) last 10minutes and if this are more then (for examle) 20, then return false (or make them parameters of the method).
Then you can protect your method (or url) with that expression (#PreAuthorize("createsNotExeced(10, 20)"))
But this is the high tech solution - it would be quite intresstion implementing them when one wants to learn spring security. (and you would need to add some caching, but this is also a Spring feature).
The lowtech solution would be: put an list of timestamp in the users session, and add an new item to that array whenever the user creates an new item. When the last (for example) 20 timestamp enties are within the last (for example) 10 minutes, then throw an TooMuchHeavyUseRuntimeException or somthing else.
I am trying to integrate two separate web applications - one is an existing custom web application with it's own security paradigm and the other is a reporting platform (JasperServer). I want to be able to use Jasper's web services interface to integrate the reporting functionality into our application. Our security model is complex and is home grown but I think there is hope.
We set a cookie that is an encrypted string containing a web service URI as the authentication source and a token which is stored in the database that is created when the user logs in and is destroyed when he/she logs out. I think I can leverage this to implement a kind of SSO in Jasper since it uses Spring Security.
What I THINK I should do is implement a pre-authentication filter that checks for the cookie I mentioned above. It could then decrypt it, make a web service call to the authentication source provided to verify the token is active in the database. If it is, that token can be used to point to user and role information that could be returned as a UserDetails object.
Unfortunately, I know enough to be dangerous but not enough to be effective. Am I on the right track? Does this solution sound tenable? If so, where would be a good place to start and are there any examples of something similar you could point me to? I've searched around quite a bit and have found nothing that quite fits the bill.
Thanks in advance to any and all who can provide me a glimmer of hope
Cookies are tied to a domain/subdomain/path and port. It is possible to set a cookie at the domain level so if you have something like webapp.mydomain.com and jasper.mydomain.com you may be ok assuming they are on the same port.
However be very careful about implementing your own SSO/Authentication framework. It requires a great deal of thought. As it stands your proposed implementation would be vulnerable to: replay, man in the middle, and XSRF attacks ... there may be other vulnerabilities but these are just 3 that come to mind ... sorry! :D