I'm looking into an "authenticated URL" type middleware for my Laravel application where a token is generated and that token relates to an authenticated user ID and the hash of a single URL. In other words, a way of viewing a session page from an e-mail without being initially signed-in, using a high-entropy token.
When the user visits the URL, for example https://www.example.com/some/url?authtoken=WDu4UQ5SQr4WGlfMYErxRy3hjdFMs02f2NqbQ7PA, the AuthenticatedUrl middleware looks up the authtoken in the database, verifies the hash of the request's URL and the stored URL match, then logs in the appropriate user ID (Auth::guard('user')->login($token->getUser())) so the page's controller can respond as normal.
That being said, I would prefer to only allow this middleware to authenticate the request itself, not the entire session. Is this possible without causing issues with an existing normal Laravel session?
I discovered the Guard::onceUsingId($id) function which does exactly this. It logs in the request without setting any related session values or cookies.
Related
Currently, I’m developing a web app with server-side rendering using the Gin framework and I’m having a problem with login intercepting. When an HTTP GET request hits an endpoint, middleware is used to check the browser cookie and redirect the traffic to the login page. This works fine and after successful login, the user is always redirected to the dashboard page. My question is how I should redirect the user back to the originally requested URI instead of the dashboard page?
Also, a bit more complex scenario is on HTTP POST. It looks like the HTTP POST method doesn’t work quite well with a redirect. Also, how would I resume the request with the same post request after the user successfully login?
Thanks for the help!
For the HTTP GET scenario, this one is easy, you need to remember the original URL somewhere. The are a few ways you could go about this:
Store the URL in session information(if any is available, you do need sessions for non-authenticated users)
Store it in a query string, for example, redirect to example.com/login?original=https%3A%2F%2Fexample.com%2Fanother-page. Your login page can look for the query parameter and include it in the login form or make sure that the action of the login form matches the given URI. On a successful login attempt you can get the original URL form the query param and set it as the Location.
Store the original URL in a cookie, upon successful login you can just check the cookie value and use that.
As for the HTTP POST scenario. If you just want to redirect the same POST request to a different URL you can use a 307 Temporary redirect. A 307 will preserve the request body and method and not turn it into a GET request like a 303 See Other or 302 Found.
Resuming the original POST after showing the login screen and after a successful login is a little more complex. When you redirect to the login page you interrupt the flow of the user, maybe it is better to let the user re-post their request after logging in, instead of doing it for them.
Having said that, it is technically possible. We require two steps, first is storing all the data to recreate the request. Then after login completion we can render a form with this saved data and use javascript to submit the form. By adding:
<script>document.getElementById("myForm").submit();</script>
After your form, the browser will submit the form after loading the javascript, thus recreating the original POST.
The storage part can be done via the server side session or a cookie.
Before adding, yes it works when I give the entire url like http://localhost:8080/onedrive/oauth2/success/1 in the list of uri in azure uris. I am using code flow to authroize these tokens.
But as per the docs, it should work with me just mentioning the domain name there, like http://localhost:8080. Which it doesn't.
I want to do something like send the user id along with every request for me to keep track of which user I should link this accees token to, and have no idea to do so, if this issue is there. My current application logic is, when my application sends the user details and calls my spring API, I want to handle all these transfer of tokens in the server side, so I want to transfer this userId as my path variable. How do I go about doing this? Has anyone done this, can they explain to me any other different solution?
You can't add custom details to OAuth redirects and it is best practice to always register the full redirect uri.
In terms of tracking the user, after login the token has a user id and you can also get fields such as user name and email - so both the UI and API will know which user each token is for. I can provide further details on mechanics if needed.
The user id in a token is often a generated value, whereas the user id you want to use in API path segments is maybe a user id from your app's back end database - if so you will need to map between token details and database details.
If you provide redirect uri as http://localhost:8080/ then it means you are handling the api response in
/
endpoint and not
/onedrive/oauth2/success/1
To get to know the user to whom you are linking, few ideas which you can use are
1) Use security to obtain the logged in user credentials (Ex: Principal if you're using Spring security in java)
2) After successful authentication, use the user id you have and send one more request to backend and store it database with userid as a key
So I need that every user would use session only once? If you loged in on one pc, I need to log out user from other. Also if IP or User-Agent changed also logout user from it.
Is there any built in options for this kind of task in laravel or I need to check each request?
When login request generate a token which is include client_ip+random number and any other.
encrypt and url encode the token and send as the response.
each and every request check that token, if not match log out the user.
I know that to protect web applications from Cross Site Request Forgery, the only secure method is implementing a CSRF token. My question is, isn't it possible to use the CSRF token to track sessions also? Why should we implement a different session id to track the sessions?
A CSRF token is a value that must be generated randomly and associated to a session (a user) in EVERY GET that shows a form to prevent false POST. This false POST comes from the user browser too so, to authenticate the POST, you need a session with the token stored in server memory to compare if the token that comes with the POST is the same that is stored in user session.
Also, web app's shuold need to identify users in a GET and CSRF tokens are only in POST.
Session need to be static to identify user along time and several request due to disconnected nature of HTTP. CSRF changes in every GET, it can not be used like session.
In the other hand. What server should do with your idea? Create a new session every GET and copy all previous session data to the new session? This is crazy.
Take a look to this pdf at Montana State University. It helps me to understand CSRF.
I have this web app written in AngularJs that uses cookies to authenticate the requests in a REST API.
Once the user logs in, the cookie is received and saved in the browser and all subsequent requests send the cookie along to the server. There is a 'User' service/object that saves the isLoggedIn and username values (for UI display/flow). Now, if I refresh the 'index' page, the app restarts. This means that my 'User' object will be cleared. I can check the existence of the cookie and, if it exists, I can re-set the User.isLoggeIn as true and go from there, but I still need to get the username, id, etc. So, my question is: should I create some sort of 'ping' endpoint in the API to verify if a cookie is valid? And if so, the API would send me back the user id and username... OR should I persist the user data in LocalStorage (or some similar cross-browser thing) and just assume the user is logged if the cookie exists? Any other subsequent requests to pages that need authentication would be automatically verified. So, this question really only applies to the scenario where the user refreshes the index page - hence, restarting the web app. I want to know the user data because I want to show a 'user homepage' instead of the 'public homepage'.
What do you think?
You should depend on the server for this. Creating something like GetCurrentUser method on the server. If the user is logged on this returns all the properties of the user.
You should even use this server api to get the user data after authentication completes. So the authentication become two step process first the user is authenticated, on success another call is made to server to get current users details.
Using client side local storage for this would not be ideal because you need to do lot of book keeping, in terms of cleaning the logged in user on log out or session expiration.
Also cookies from server would have expiration times an all, and making decision just based on cookie existing on local storage may not be optimal approach.