The flashing system basically makes it possible to record a message at
the end of a request and access it on the next (and only the next)
request
Please can I have an example wherein a msg recorded at the end of a request will need to be accessed in the next request?
flashing is very useful for websites.
Let's say you have a login system on your website and you want to notify user after they logout, then you can simply add a flash message saying something like "You have been logged out!"
Everything works fine without flashing but it gives extra confirmation to the user and makes website more user-friendly.
Related
I have my api behind a third party OAuth (ex. google, twitter, etc). When a user hits /api/login, they are redirected into the OAuth flow and then sent back to my callback /api/login/callback. I store their login info and then send back a same-site http only session cookie to validate their user id. On subsequent requests, I retrieve that session cookie to get their user info and then perform requests using the OAuth token stored earlier.
Now, I want to create a frontend to go with my backend REST api. When a user goes to my / route they get a generic about page along with a sign in button. The sign in button redirects to my /api/login route and eventually back to my /api/login/callback. Now, the callback will redirect again to the / route. Subsequent requests made will have the session cookie attached and will go through.
My problem arises in that I don't know how to communicate to my frontend that my user is logged in. Because my session cookie is http only I can't access the cookie on page load to render a different UI for logged in users.
Some ideas I've had:
Hit up a /api/me URL that returns 401 or 200 depending on if the session cookie was sent. The problem with this is that this will leave the frontend in a limbo while the request is resolving.
Make the cookie not https only. However, I've read online that this makes it vulnerable to XSS attacks.
Send a second, non https only cookie as well to show that the session cookie exists. If this cookie is tampered with the worst that can happen is that a user will receive a 401 error later down the road when they make an API call without the session cookie.
Put something in local storage or in a cookie before the request to signify a user hit log in and check for it on page load. However, I won't know if the login succeeded or not.
Create a second page specifically for unsigned in users on the / route. Then, the callback can redirect to /signed-in. However, how will my /signed-in route know if a user navigated there or if the server redirected them? (ex. if the user autocomplete's the browser bar to the /signed-in route after their session expires)
Out of all these the third approach seems the most viable (the second cookie). However, this seems like a very trivial problem that someone has solved before. What am I missing here?
Note: I don't want to use ssr here. If I was using ssr I could simply just check for the session cookie server-side on the / route and reply with a different HTML template.
Edit: I could combine ideas 3 and 4. Put something in a store before sign in. If sign in fails, have my server redirect to a /fail page. If not, redirect to /. Then, / can reload the store on page load. /fail would also delete the stored item so that a user who failed can't just immediately go back to / and see they are logged in. The only unauthorized people who would see my user ui on / would be
Users who close out of the page during their login (never finish their login so never redirected to /fail to delete the store)
Users who revoke their OAuth token. This will have to be caught later down the road when my server receives a 401.
I could also add in a third "authorizing" state. I would set this before login. On page load with the authorizing state, I'd make a request in the background to validate that the user finished signing in. If I get a 401 from my server I'd have to move the user out of the authorized page. It wouldn't be nice but it'd occur less often than if I didn't use the store.
Before hitting sign in set a temporary loading value inside a store (cookie, framework store, localstorage, etc).
If the callback URL receives a failure value, redirect to the /fail route. /fail will set a failure value inside the store and redirect to /.
If the callback URl receives a success value, redirect to the /success route. /success will replace the temporary value with a success value.
On page load, read the store.
If the store is empty its a new user.
If the store has a temporary value, they never get redirected after the callback. Show a toast about an error and then display the sign in page.
If the store has a failure value, they failed the OAuth. Again, show a toast and display the sign in page.
If the store has a success value, everything went right. Show the user UI.
Eventually, the user may want to revoke their token. If they do, my app will not know until I make a request to a protected api endpoint with their token. If so, just pass the 401 to my frontend. I can show a modal saying they are unauthorized and then replace the success store value with an empty value.
I am building an expo app that leverages auth0 for authentication.
I have trouble switching to another account after I have successfully logged in and logged out. The details reproduce steps are:
Pull the project, yarn install && expo start --ios
(Optional) For your safety, replace auth0ClientId and auth0Domain in App.js with your own auth0 info
Press "Log in with Auth0", get a prompt, and finally see something like below
Log in with gmail (there should be such an option, even though it is not in this picture)
If you successfully log in, you should be able to see "You are logged in, !"
Press "Log out"
If you try to redo step 3-4, you are no longer able to see the universal login page as shown in the picture. Instead, you are logged in directly.
This thread describes the same behavior but he assumes it is client that caches the authentication info in cookie. I don't think this is the reason. I believe auth0 caches the first logged in user on server side and return the cached result regardless. My evidence: I add this console.log at https://github.com/ocdexperience/auth0-example/blob/master/App.js#L68 and every time I try to log in, this line always print that's why I guess await AuthSession.startAsync({ authUrl }) returns the cached result directly.
Thank you for the help.
It sounds like you are being logged in via silent authentication. This does indeed use a session cookie. To fully logout the user you must clear the cookie, or use the recommended method of utilizing the /logout endpoint.
You can test this by logging in with an incognito/private browsing window, or by clearing the cookie before clicking the login button the second time.
I am building a voting mechanism for a site. A similar one seen on Stackoverflow.
For instance, if user clicked up-arrow, vote = True. If he clicks again on it, vote = None. The app is working fine except if we submit votes very fastly.
We tried to click arrows very very fastly and see how voting is happening by logging the data. Unfortunately, we are seeing some misbehavior. By fast, I mean, clicking the arrow continuously without stopping for some seconds!
The expected log data should be like
vote=True
vote=None
vote=True
vote=None
..
But I observed it like
vote=True
vote=True
vote=None
vote=None
The observed log data mentioned as second case, seems to be a bit unordered..
This could mean that the requests received by django are not handled as a queue! Which in our case is a bit dangerous. Or database is taking some time to store and during that period another requests are handled which is causing the error.
I hope you are understanding my issue. So, I am wondering if you can let me know what's going on here and how to control it.
You cannot make assumptions about the order in which a browser sends (asynchronous) requests, the order in which they arrive at the server and the order in which they are handled by a single or multi-instance (threaded, worker) Django application.
So what you describe above is what you actually might expect. Doing synchronous requests may help a bit. The best option is probably to (asynchronously) wait for the server's response before allowing further clicks.
You must be having a flow similar to this:
-> User clicks button
-> check if user has already voted up
-> if no:
-> vote up request goes
-> vote up after validation
-> response is sent back to browser
-> else:
-> vote none request goes
-> remove the vote after validation
-> response is sent back to browser
If you don't disable the button for the time when a request has already been sent and its response is awaited, then you will get into such situations.
Say, request1 was considered a vote up and request was sent.
Before request1's response came and user clicked again, then this request will also be considered as a vote up, which is not what you expect.
You should either disable the button, just before making the ajax call and enable it again when the response is received.
Or whenever user clicks, you should flip the button type i.e. make it vote-none for vote-up request and vice versa, even before making the ajax call. And when the ajax response is received, validate the previous action again. It will vary only in cases, when any validation fails on server side, like the user might not have permission to vote up.
You can see this happening in SO if you try to vote-up your own post. It first changes to vote-none mode and then later when the response is received from server, it changes back and also gives an error message.
PS: I tried to vote-up my own posts for educational purposes only ;)
I'm new with Jmeter and by default sorry for dump question.
I want to start with the most basic testing for web site. I want to login to application and navigate to specific page. Basically, that is it for now.
I was fighting with this issue but unfortunately I cannot save cookies properly. I use the following test scenario:
However, after I start to run scenario I can see that login was executed successfully, but navigation on page redirect to Login page.
It seems that cookies were not actually saved.
Please any advice. If you require any additional information I'll provide everything what is needed.
What makes you say login did not work or work ?
Why don't you first look in View Results Tree at first "Http Request login" sampler response to check that login was successful ?
To see if Cookies are transmitted check Request Tab in View Results Tree to see if Cookies are transmitted.
From what you show it seems you are playing login twice, check your Thread Group for number of iterations ? if you set more than 1, maybe your application does not allow double login.
We have an application that allows to users publish content to their friends wall.
It uses the user's access_token given our application.
It works stable usually, but for some reason for one of our clients it doesn't work at all.
We've checked permissions several times, removed-added them again, but still no result.
There is no error message or something, everything looks fine, complete the action, but no posts published in fact. And it doesn't work only for one person.
What possibly can be a problem?
Updated: The problem is actually in this OAuthException:
Error validating access token: Session does not match current stored
session. This may be because the user changed the password since the
time the session was created or Facebook has changed the session for
security reasons.
We tried to get access token one more time, but that didn't help. Somebody familiar with this issue?
your user might forbid people/applications to post on his wall.
"There is no error message or something, everything looks fine, complete the action, but no posts published in fact."
Are you sure about this? You should be getting back a unique stream id of the feed item just posted.
Facebook frequently changes its policies that sucks!
Now, you need permission to access the wall.
You need to check if the user has permission to access your application / wall page. if user hasn't got permission then you need to ask for permission before message is streamed. Yes, that's true, it won't display any error message, unless you manually debug this to see where it is stopping.
My suggestion is:
1. use FB.login method to verify, if the user is not logged in then he should login
2. verify the user permission for the wall page
FB.api('/id', function(response){});
3. publish / stream the comments on wall
FB.api("/id/feed", 'post', { ... blah blah blah !
edits:
At FB.login method, you should ask for permisions
e.g. FB.login(function(response) {..} ... ,{scope: 'offline_access,publish_stream'});