On a webpage, is it safe to block a submit action after user clicked it once (to avoid double posting) or is there a risk that I now block my user, in case of no/bad connectivity, post not reaching the server etc..
So in other words, can I trust that my post request always reaches the server and back to the user?
It is ok to disable button on Submit... but please make sure that you execute SUBMIT script after you have disabled it...
p.s. Common behavior is that submit button does not proceed to submit after you disabled it, you should do it manually.
To encounter no/bad connectivity, you can set javaScript timer that will return submit button to its normal state after some time, so user can click it again
Ideally you should send a server call and disable the submit button and wait for the response to comeback and if status is failed enable submit button otherwise do nothing and process the response as you need it
i think you are using javascript for making a server call if yes then it's very easy to pass a callback and listen for the response
Related
I need to receive a notification when authentication on the client happens.
I have an item with key:
log[/var/log/auth.log,(sshd.*)?(Accepted)]
Also I have trigger with key:
{test.test.ru:log[/var/log/auth.log,(sshd.*)?(Accepted)].str(Accepted,#1)}=1
I need that there will be only notification without raising a problem. With my config I always should deactivate the problem and I receive a second notification I don't need. How can I make notification without an obligation to close the problem or to receive second notification?
Suppose that this is impossible... What meets my requirements most is to make a specific action for this trigger and do not make a recovery step for it.
In the trigger configuration, you can select "Problem Event Generation Mode" = "Multiple" to have multiple problem / notification.
An Action can have no Recovery Operation and works just fine.
https://www.zabbix.com/documentation/current/manual/config/triggers/trigger
I have a page using angularjs, everything looks good except one thing: after user clicked submit button and the server side validation failed, the user input will be gone, but when I checked the html tags, the value="xxx" attribute saved the lost value, how can I get and render it to my page?
Thanks a lot!
Not sure about your exact scenario, but what you can do is to make the copy of original model object and bind it to form
$scope.editItem = angular.copy(originalItem);
Bind editItem to the form.
If the server validation fails just call the above statement again and the editItem would be restored to original value.
I'm seeing multiple submissions on a form, presumably because someone is double-clicking a submit button. Is there a good way to prevent this in GAS? I suppose I could set up a global variable via JSON, and use that to determine whether or not to execute the handler, but it seems a bit clunky.
Thanks.
create a client Handler that disables the submit button before the rest of your code is executed.
You can add a client handler anywhere you would add a server handler of any type, and it works entirely on the client without any server roundtrip.
See Serge insas comment below!
Background: We are in the process of writing a registration/payment page, and our philosophy was to code all validation and error checking on the server side first, and then add client side validation as a second step (un-obstructive jQuery).
We wanted to disable double clicks server side, so we wrote some locking, thread-safe code to handle simultaneous posts/race conditions. When we tried to test this, we realized that we could not cause a simultaneous post or race condition to occur.
I thought that (in older browsers anyway) double clicking a submit button worked as follows:
User double clicks submit button.
Browser sends a post on the first click
On the second click, browser cancels/ignores initial post, and initiates a second post (before the first post has returned with a response).
Browser waits for second post to return, ignoring initial post response.
I thought that from the server side it looked like this: Server gets two simultaneous post requests, executes and responds to them both (unaware that no one is listening to the first response).
From our testing (FireFox 3.0, IE 8.0) this is what actually happens:
User double clicks submit button
Browser sends a post for the first click
Browser queues up second click, but waits for the response from the first click.
Response returns from first click (response is ignored?).
Browser sends a post for the second click.
So from a server side: Server receives a single post which it executes and responds to. Then, server receives a second request which it executes and responds to.
My question is, has this always worked this way (and I'm losing my mind)? Or is this a new feature in modern browsers that prevents simultaneous posts to be sent to the server?
It seems that for server side double click prevention, we don't have to worry about simultaneous posts or race conditions. Only need to worry about queued up posts.
A similar situation that you need to handle (that the javascript disable-submit-button solution doesn't cover) is the one where the user clicks Submit, the server processes the request, but while it's processing the user's internet connection goes down (perhaps they're on a train going into a tunnel).
When the train comes out of the tunnel, the user doesn't know whether their transaction succeeded or not - they pressed the button, but nothing changed on the page (or perhaps they got a "Try again" page). The natural thing for them to do is click Submit again (or the "Try again" button).
The best way to handle this situation is to include a unique transaction id in the form (in a hidden field). Generate this id randomly, and when a transaction is successfully processed, store it in the database in a list of completed transactions.
Then when you get a POST, check whether this transaction has already been seen - and if it has, skip straight to the status page. Roughly:
BEGIN TRANSACTION
SELECT *
FROM completedTransactions
WHERE userId = ... AND transactionId = ...
<if we got a result - display results of previous transaction>
<otherwise - process the request as normal>
INSERT INTO completedTransactions (userId, transactionId)
VALUES (....)
END TRANSACTION
This has the advantage that (provided you have a database that properly supports transactions - and since you're processing payments I hope you do!) you don't need to do any sort of threading or locking - things "just work".
(though be careful - some database systems can arbitrarily abort your transactions if there is a concurrency problem - but this (rare) situation is easily dealt with using a retry loop...)
As to testing double clicks from browsers: does it make any difference if you press the "stop" button between the two "submit" clicks?
this may be a stupid response, but why dont you just disable the submit button with javascript on click, so you dont have to worry about multiple clicks. i usually do this on most forms i make and it seems to solve the problem.
you already said you are using javascript so thats not the issue right?
As long as the request is in its connecting or sending stage, clicking on submit during the first submission cancels the request, starting a new one without the server 'knowing'.
Say a user is browsing a website, and then performs some action which changes the database (let's say they add a comment). When the request to actually add the comment comes in, however, we find we need to force them to login before they can continue.
Assume the login page asks for a username and password, and redirects the user back to the URL they were going to when the login was required. That redirect works find for a URL with only GET parameters, but if the request originally contained some HTTP POST data, that is now lost.
Can anyone recommend a way to handle this scenario when HTTP POST data is involved?
Obviously, if necessary, the login page could dynamically generate a form with all the POST parameters to pass them along (though that seems messy), but even then, I don't know of any way for the login page to redirect the user on to their intended page while keeping the POST data in the request.
Edit : One extra constraint I should have made clear - Imagine we don't know if a login will be required until the user submits their comment. For example, their cookie might have expired between when they loaded the form and actually submitted the comment.
This is one good place where Ajax techniques might be helpful. When the user clicks the submit button, show the login dialog on client side and validate with the server before you actually submit the page.
Another way I can think of is showing or hiding the login controls in a DIV tag dynamically in the main page itself.
You might want to investigate why Django removed this feature before implementing it yourself. It doesn't seem like a Django specific problem, but rather yet another cross site forgery attack.
2 choices:
Write out the messy form from the login page, and JavaScript form.submit() it to the page.
Have the login page itself POST to the requesting page (with the previous values), and have that page's controller perform the login verification. Roll this into whatever logic you already have for detecting the not logged in user (frameworks vary on how they do this). In pseudo-MVC:
CommentController {
void AddComment() {
if (!Request.User.IsAuthenticated && !AuthenticateUser()) {
return;
}
// add comment to database
}
bool AuthenticateUser() {
if (Request.Form["username"] == "") {
// show login page
foreach (Key key in Request.Form) {
// copy form values
ViewData.Form.Add("hidden", key, Request.Form[key]);
}
ViewData.Form.Action = Request.Url;
ShowLoginView();
return false;
} else {
// validate login
return TryLogin(Request.Form["username"], Request.Form["password"]);
}
}
}
Just store all the necessary data from the POST in the session until after the login process is completed. Or have some sort of temp table in the db to store in and then retrieve it. Obviously this is pseudo-code but:
if ( !loggedIn ) {
StorePostInSession();
ShowLoginForm();
}
if ( postIsStored ) {
RetrievePostFromSession();
}
Or something along those lines.
Collect the data on the page they submitted it, and store it in your backend (database?) while they go off through the login sequence, hide a transaction id or similar on the page with the login form. When they're done, return them to the page they asked for by looking it up using the transaction id on the backend, and dump all the data they posted into the form for previewing again, or just run whatever code that page would run.
Note that many systems, eg blogs, get around this by having login fields in the same form as the one for posting comments, if the user needs to be logged in to comment and isn't yet.
I know it says language-agnostic, but why not take advantage of the conventions provided by the server-side language you are using? If it were Java, the data could persist by setting a Request attribute. You would use a controller to process the form, detect the login, and then forward through. If the attributes are set, then just prepopulate the form with that data?
Edit: You could also use a Session as pointed out, but I'm pretty sure if you use a forward in Java back to the login page, that the Request attribute will persist.