I am building an GWT application with lot's of forms. I am using gwt-platform with its dispatch module.
The next step in my mind is to prevent double-submits ON SERVER SIDE. The problem is that I don't know how to do it exactly...
I thought of something like this:
When application loads the server gives some generated token to the client
The server stores the token inside HTTPSession
When the client submits a form it will send the token from (1.) along with the form
The server checks if the sent token == token inside HTTPSession
In the answer to the client it will send a new token
Is it safe to store the token inside HTTPSession? Or should I simply create a HashMap on the server that maps from SESSION_ID to generated token?
Or maybe there is already an implementation of that in GWT or gwt-platform or somewhere else?
Thanks
The question you'll have to ask yourself first is: What is the kind of problem scenario you want to avoid?
The user accidentally (or out of frustration, ...) clicking a button twice.
A resource that is available only once (like a reservation for a certain seat in an airplane) being consumed twice.
Don't just say "I want to avoid both". Even if you do, you'll have to deal with the two problems separately.
Problem 1
This is better solved on the client side (e.g. by disabling the button once it is clicked).
It can also be solved on the server side (by checking sequence numbers or tokens or maybe the hash code of the contents, ...), but I don't really see the point. If the user really wants to submit twice (e.g. by manipulating the JavaScript such that the button doesn't get disabled), then just let them: Problem 1 is not about security.
Problem 2
This must (except in very specific situations) be solved on the server side. It's chiefly about security. But when you think about it, this problem can't be solved by double-submit prevention! Why not?
Let's look at our example: A seat in an airplane must be reserved only once. This can be violated in multiple ways:
By double-submit.
By the same user submitting at the same time e.g. from different browser windows.
By mutliple users trying to reserve at the same time.
The clean way to solve the problem is to check for availability of the seat atomically with reserving the seat. It doesn't really matter, if a violation was caused by double-submit (accidental double-submits are covered by problem 1).
... and Problem 3
If you have implemented some auto-resubmit mechanism, then you might also encounter a third kind of problem:
Let's say the user wants to add an item to his shopping cart. The client submits, and doesn't receive a response from the server before time-out. So it sends again automatically. The server however receives both messages, and tries to process them both - so it adds the item twice to the shopping cart.
The best solution to avoid this in my opinion is generally not to use actions like "add one item to the cart", but "set the target count of items to 1". Again, you could also work with sequence numbers etc.
Related
I am dealing with a Private caller case where the Privacy header is only passed in the initial INVITE but not in the subsequent mid-dialog requests (e.g. CANCEL).
When the Privacy header is present, my downstream expects me to send them another header.
For the most part, I was able to deal with this by using dlg module to keep track of state within dialog so that the mid-dialog requests will know about the Privacy header's presence in initial INVITE.
However, a problem i have is that just for the CANCEL request, I am unable to add any headers to the SIP request relayed to downstream.
I've read in other posts (dated years back) that an option would be to use stateless CANCELs downstream. Another potential option would be to start a new transaction at my level.
I am wondering if there are other alterantives to this. I would've recommended my downstream to use $avp but it seems like even though initial INVITE and the CANCEL are supposed to be in same transaction, the $avp value stored in initial INVITE is not accessible by the CANCEL.
There are other tricks that can work. Such as using the Record-Route as a data store (that can be security issue) or asking downstream to use dlg module, which can be a big performance cost to the,.
I am wonder if any of you have solved this problem already.
Instead of dialog module , i prefer that using htable to store transaction until get ACK. It is faster than it . After getting ACK , stored transaction can be removed.
In addition , You can look at TM module and TMX module that has features about Cancel.
I have a very old ASP.net Application with a Web Form with 1 Dropdown Box and 2 Text Boxes and a Submit Button.
All 3 are mandatory fields. Based on the data entered, once the user clicks Submit Button additional details are shown on the next page from the database.
On Submit data is posted via Query String that looks like
http://myserver/myapp/search.aspx?f1=1&f2=tom&f3=sales
Though the application is doing what is supposed to do, off late we came across lot of issues:
As couple of entities that are interested in our data wrote programs to programatically build the querystrings and hitting our server.
This is slowing down the server and regular users who manually search records are facing lot of slowness.
Due to come legal restrictions we couldn't implement CAPTCHA or have users get authenticated.
I would appreciate if you can let me know if any of you have come across this kinda situation and how you have dealt with it.
Thanks in advance.
You could implement source-based rate limiting. I.e. per IP address only allow so many requests per minute. If the requester makes too many requests you simply reject the requests. You could also blacklist the IP addresses that are hitting your app too aggressively. Both of these policies can be enforced by a load balancer like HAProxy or nginx.
I was having the similar problem as mentioned in the below link, Select and Display the table in oracle APEX mail body. I followed the mentioned steps and it worked!! .
Now, I just want to extend the same question and wanted to know, Is it possible to manipulate the the database through click on the button in the mail?
If I crate the html Button APPROVE, It should be able to manipulate database table.
Suppose, APPROVE performs delete operation: delete ename from emp where dno=10.
VERSION : ORACLE APEX 4.2
If you are sending an HTML email to a user and you want that user to interact with the system from the email, you could generate an HTML form that submits to a particular URL (some APEX page with some set of parameters) that actually implements the DELETE.
Assuming that the client email application would allow the user to submit a form, which would generally be a security issue and would probably not be possible from some clients, you'd probably have security issues to worry about on the server side. I'd assume, for example, that you don't want to allow any random person that works out the URL to call to be able to delete whatever row you want from your system. You probably want to require that someone is logged in before you'd allow them to delete a row. And you probably want to make sure that they have permission to delete that particular row.
It's certainly possible that you could work around both the client and the server side permission issues by doing something like creating a unique token that expires after a short period of time and gets passed in with the form to verify that the user has permission to delete that particular row. But by the time you're building that sort of infrastructure or sending users to a login page, you're probably better off just creating links in your email that point to a page in your application and letting users go there to request the actual delete. That's going to work more reliably than a form that submits a request and it will probably involve less work for you.
I've developed an app that allows users to upload some photos and share them on Facebook/Dropbox/Twitter etc. Recently it went live in the app store.
However, I'm having a problem now: a bot is creating accounts and uploading many photos on my server. I've temporarily disabled the app, but now I'm looking for an efficient way to prevent this bot from doing this.
The bot's ip address is changing very often so it's impossible to block the ip. He creates accounts with a very realistic name and email address so it's hard to find out which users are real and which are created by the bot.
I was thinking of using a captcha, but I'm not sure if my app will be rejected by Apple if I implement this. I'm preferably looking for a way so I can prevent him from doing his work and so I don't have to resend the app to Apple again.
Could anyone give me some advice on what I could possibly do?
Thanks!
This is how I solved a similar problem:
I implemented a token-generator, which generates a one-time token for every single data transfer with the server, so even one for login-data, sending a file etc. This token is generated by a secret algorithm and can be verified server side, since you know how you generate one.
After one token is used, put it in a temporary list for the next X minutes/hours/days (depending on how many data transfers your server can handle). When a user tries to send data with a used token (i.e. the token matches one in the "banned" list), you can be sure that someone's trying to spam you -> mark the account as "spammer" and decide what you wish to do.
The algorithm must produce a different token each time (the best way would be a one-way hash), but you have to assure specific "properties", with which you can proof its authenticity.
So one very simple example:
Your algorithm in the client is generating a number between 1000000000000000000000 and 99999999999999999999999, this number is then multiplied with 12456564 and incremented by 20349.
The server becomes a specific command and data, and the generated token. Now it checks, whether (number - 20349)%12456564 is 0. If it's 0, it was likely generated by your "secret" algorithm.
It's a very basic example but you get the idea…
I am considering making a very simple form for clients to use in a sort of web browser kiosk fashion, where they submit some of their information through the computer in the lobby at their option instead of writing something out by hand. This would be used if they come in person rather than calling or going to the web site first. I already have a form on our site for clients to use from their home computers so this would be very similar but tailored for and only used for the in-person clients.
Since the form will sort of just loop back to itself (not really "back" but just have a link to go back to a fresh form) for a fresh form after every client, how can I ensure that one can't hit back a few times to see the previous client's info? It's not really sensitive data, I just would like to provide that bit of privacy. Of course clients using our web site and the form there from their own computer are responsible for their own privacy.
Apart from having customer service walk to the computer and close and reopen the browser, or using AJAX, what should I do?
The other topics I've read related to this all have someone basically saying "you're not supposed to do that, you bad person". This seems like a valid reason to me. Any ideas?
Thanks!
Disable autocomplete by adding autocomplete="off" to the input tags or form tag.