App was developed in Web API. We are using AntiForgery Token validation for all the POST calls in xyz.com. Registered xyz.com users get email alerts for the contents they are signed up for. Users click item from email to view the content details. On click of item first click event is being saved in SilverPop and silverpop redirects to actual content in xyz.com. Details page is being loaded with out any issues after authenticating the user based on few query string parameters. Issue is when user make a post call(to saving for later, book mark etc) App is throwing Antiforgery token mismatch error. Sorry for bad English and long question. Strange part of this issue is We are unable to replicate this error and its not occurring consistently. We have two server and 1 load balance hosted in AWS not using sticky session enabled. Using Forms cookie authentication. finally, this issue kept occurring though we run with 1 server. Thanks for reading and appreciate if any one could help.
*User must be Authenticated to validate CSRF token ? This xyz.com makes few api get and post calls.
Related
I am using Laravel as my backend together with Sanctum which generates personal access token for mobile users. For my mobile application I am using flutter.
To authenticate users they login with their username/password and get a personal access token in return. This works but requires a user to login every time they open the application again so I did what most tutorials suggest which is saving the token on the mobile device using shared preferences/secure storage.
Now comes the question how do you invalidate a user when you remove their token from the backend? On initial login it appears everything is still fine because like in most tutorial I check for the existence of a token. After that whenever I want to make a request which uses the token I obviously run into problems because it not longer exists on the backend.
Most tutorials/guide suggest saving the token and using that a reference to see if the user is logged in or not but this seems flawed because it gives the false impression you actually have a valid token.
My guess is this can be solved by always performing a heartbeat/ping action to check if the current token is valid and if not send them to the login screen instead of simply checking for the existence of the token.
Thoughts on this?
I can suggest a hack or trick here in every launch of the app you can send a request to an API to check if the user's token is valid or not and if it is valid then you can continue the app otherwise force the user to login and generate new token this way your app will be secure via server / API.
For this, you can store the user's secret token in the database and check it via HTTP API call and send a response from the API accordingly and check the response in app and do the next operation according to the response you get.
I don't know if this is a great way of doing this job but it is a kind of hack/trick to achieve what is needed.
Thanks
I have built a mobile app using React Native.
This app connects with a REST API I built using the Laravel framework.
This API is hosted on a VPS and served over HTTPS.
The mobile app works as intended where I expect it to, with the exception of the following use case:
A user has an iPhone 8+. This user’s carrier is AT&T. The 5Ge, to be specific.
This user can download the app and install it no problem.
When they open the app, the app connects to the API, and gets the data to display on the home screen.
The user can login, using their credentials, which are sent to the API, and the API returns an access token on a valid login.
Every subsequent request, is sent with an Authorization header: Bearer [token]
These requests specifically, never reach the server. All authenticated routes for the API are unreachable for this user.
Users on other networks, like Verizon and TMobile, do not have this issue.
The mobile app uses Axios library for sending HTTP requests.
A timeout of 25000 (maximum that can be sent on the iOS?) is passed as an option to the authenticated action. The action fails for this user.
The error is caught and then sent to a public route on the API, without an Authorization header in the request.
This request reaches the server and adds the error message from the request from the mobile app, to the error log on my server.
When I inspect the error that was thrown by the authenticated action failure, it reads “Network error” with a code of 0.
If the timeout is set lower, at 15000, the error thrown by the failed authenticated action is a timeout error, exceeded 15000.
I have contacted AT&T today, and they said we should contact Apple.
After they patched us through to Apple, Apple said issue sounds like it is a cell tower issue, and offered to run diagnostics on the phone.
My question is: Why are the requests that contain an Authorization header Bearer token not able to reach my server when the user is on the AT&T network. Is the bearer token making the request bulky and slowing down the request to where our towers aren’t able to send it?
Or does AT&T have some kind of middleware that would trash the request for some reason?
Could the Authorization header cause AT&T to handle the request differently and send it some other way and in this way could DNS errors cause the request to fail in this way.
Please help, I hope I have explained it well enough.
Edit: Laravel Passport generates access_token for the authenticated API that is 1000+ characters in length. It looks like I can reduce that by about half. I am going to try that next.
I'm finding this is resolved now.
I did two things. I reset my Laravel Passport keys with a specified --length of 1024.
This resulted in my access tokens being around 557 characters long instead of 1000+
I also made some DNS changes in my subdomain. A scan I did showed a nameserver parent mismatch error between the subdomain and parent domain. I made the changes and got those warnings to go away.
These are the things I did. My two app users who are with the AT&T network carrier tested the app tonight after I did these changes.
They logged in. Opened the timeclock. Clocked in. And that request made it to my server like it was supposed to, with the new shorter access token.
I don't know which one of those two things fixed this issue. But I would probably guess it was the DNS problems that I resolved. I still find it odd that the issue only occured on the AT&T network when with an Authorization token in the header of the request.
I am working on a website which is developed in react js and I am fetching all data through the API calls. That API calls are visible in the network section of a browser and that API call contains JWT token in the header part of all API call, So it can cause security issue due to that anyone can do that API call with the same header and same URL through other platforms like postman n all.
So my question is that how can I control that no one else is able to access it or how can I hide that API calls from the network section of the browser?
Is there any other solution to solve this security issue?
You have to assign a token to each user. The token will be given to the user upon authentication.
You have to manage access to the page based on the userId and token.
Yo should not use generic tokens for all the users.
Destroy the token upon user logout.
If the user see the token on the network they can only have access to the portion that he is suppose to have access.
This is how I do it, hope it helps.
I want to ask you how does sites like Facebook etc. handle user authentication on the page refresh? I wonder why I don't see any loader when I refresh the page and I'm on the protected route (e.g. my profile settings).
When I create an application I use following authentication flow:
Load the application
Show authentication process loader to the user.
Get user session token from the cookie.
Send authentication request with the token to the backend.
Validate the token on the backend.
Send a response to the client with the status code 200 if token is valid or status code 401 if token is invalid.
Receive a response on the client side and hide the loader.
Show protected route to user if he is authenticated or redirect to the login page when he is not authenticated.
So with such a flow initial loader is a necessity, how facebook is able to omit that?
and welcome to Stack Overflow.
I'm not sure your question is valid - pretty much every page on Facebook requires you to be authenticated (not just the profile page), and authenticated access is a common feature of pretty much every major website; they rarely show loading bars.
We don't know exactly how Facebook is built, but it's a fair guess they use React; you can read up on how to manage authentication on React here.
Your flow is predicated on the assumption that there is an "application" to load, and that the authentication request will take substantial amounts of time. If your token validation is fast, this assumption is probably incorrect. You do see "loading" animations on React apps - if you scroll down your timeline on FB really fast, you see the circle; this is probably partly network, partly retrieving the posts.
I figured it out. It's possible because authentication can be done on the server side using cookies. They validate user token when user enter the page and after this they render desired version of page (different for authenticated and different for not authenticated user).
Using the new outlook rest api's to import contacts from outlook/hotmail email accounts. There is a minor glitch though, once the user clicks the import contacts button and the initial MS auth dialog pops up (url - login.microsoftonline.com), as soon as the user finishes entering their email address, the page suddenly redirects to login.live.com.
This is bad because:
this happens without any warning (user could be in middle of entering their password for example)
what's the point of using the new api's if the auth is still being handled by the old live connect api endpoint.
Would like to know if there is anyway to prevent this redirect from happening?
Maybe I am missing some param which needs to passed in to the initial auth url?