django messages get displayed only on the next request - django

I have a django app and I use messages in order to show some limits that user passes.
My problem is that all my messages are shown after the second request.
I mean, after adding a message and going to a page where the the message should be shown, I don't see it, but I start seeing it after a refresh.
What am I doing wrong?

This is probably how those messages are intended to work: You "trigger" them e.g. to show success/failure and then redirect to another page where it's displayed. Remember: In case an action succeeded you should never stay on the page requested via POST but redirect so reloading won't re-POST whatever was sent.

Related

What is an use case of flask flashing?

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.

Sails/Waterlock password reset flow

G'day all,
Does anyone have any experience with the Waterlock flow for passsword resets? I've hit a wall which I can see a work-around for, but it seems really in-elegant, so I'm probably missing something.
When I send through an auth/reset POST with an email element, the system proceeds to shoot the email out as planned.
When I then submit the received link in a POST request, with a password element, I see a "404" response.
HOWEVER
If I submit that link as a GET request first, and then submit the POST it works.
When I look into the waterlock-local-auth source, the reset POST action is testing for the presence of a decrypted token in the request object before allowing it to proceed.
SO
Either I code my front end to send a get request (which doesn't respond properly) and then resubmit as a POST, or I go in and hack the waterlock-local-auth code to include a decode of the token (which is what I'm thinking is the most elegant solution).
Any clues?
Thanks,
Andy
I have got a similar problem, but I use angularjs as my frontend. This discussion thread is very helpful:
https://github.com/waterlock/waterlock-local-auth/issues/7
Basically, you are expected to submit a GET request to the url received in the password reset email. After you click the link with the token, you will find in your database that a new ResetToken record has been created and the value in the token column is exactly the one you see in the url. Then you should be redirected to the forwardUrl in waterlock.js setting, where there should be a form or anything that can make you post to:
http://yourdomain.com/auth/reset?password=newpassword
Then the password is reset and the ResetToken record will be removed from your database.
If you look at the handlePost function here:
https://github.com/waterlock/waterlock-local-auth/blob/master/lib/controllers/actions/reset.js#L68
This can explain why POSTing to the url sent to you in the reset password email returns 404. The resetToken must exist in session already in order that issuePasswordReset to be invoked. And the only place to set req.session.resetToken is within validateToken method:
https://github.com/waterlock/waterlock-local-auth/blob/master/lib/controllers/actions/reset.js#L188
So you need a get request first. Hope this helps.

Does Django process requests as queue?

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 ;)

Cannot save cookies for JMETER

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.

Django: do I need to do HttpResponseRedirect to render a simple string after a POST?

I've got a mobile app that makes POST requests to a Django site.
I want to return a simple string (not a template-based page) after the app makes the POST request, saying 'Success' or 'Failure' (EDIT: plus a bit of extra info) as appropriate.
****EDIT: note that it's not a browser making the request, it's an app (so there's no BACK button involved) and I'd like to do some extra app-side work based on the results of the POST request - basically I want to hand back some information.*****
However I know that after a POST request in Django you're supposed to do a HttpResponseRedirect. But, do I really need to redirect to another page and write a new function to handle it, all to output a string?
And if so, how do I pass the success/failure status of the app in the HttpResponseRedirect, since it's only supposed to take one argument?
Thanks!
If this is a user-generated POST (standard web site), then S. Lott's advice is correct.
But if you're POSTing as an API call, then just return the string. On a mobile device, the customer pays for every HTTP request.
do I really need to redirect to
another page and write a new function
to handle it, all to output a string?
Yes.
If they hit "Back" on the browser, you'll wish you had provided a redirect-after-post.
If you don't redirect and they hit "Back" on the browser, they could repost the form again. You probably don't want to deal with that, so it's easier to redirect after post.
how do I pass the success/failure status of the app in the HttpResponseRedirect
See this: http://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpResponse.status_code
Edit
If there's no browser, then there's no back button. Since there's no back button, there's no need for a redirect.
"after a POST request in Django you're
supposed to do a HttpResponseRedirect"
Doesn't make any sense. You're not "supposed" to do it. Django helps you do it.
You do not redirect after POST as part of web services.
You must redirect after POST to help people use their browser.
As S.Lott says, yes you really do want to redirect.
However I'm not sure what you mean about showing the 'success/failure status of the app" after the redirect. The redirect should only happen if the POST was successful; otherwise, you'd redisplay the form with any validation errors showing.
Is there javascript? Then maybe you could make an ajax request and simply change the content after the result comes. That should also prevent problems from 'Back' and you don't need to redirect.