I have a Java page that uses embedded JavaScript to create a confirmation message (I'm using window.confirm). I would like to use the results of the user's selection (either "Yes" or "No") outside of that JavaScript snippet but I'm not sure how. To clarify, I know how to check the user's selection in JavaScript but I am trying to pass that along to rest of the page, which is written in Java.
Supose I saved that result in a hidden field on the client side and wanted to pass that value as an argument back to the server to be used in Java. Would that be possible? And if, so, what is the correct synthex to access the value of that hidden field or other intermediary object?
UPDATE: The decision is to whether or not I want to save a record to a database. Clicking on the Save button brings up the Confirmation box (written in JavaScript) and also triggers a postback triggering and within a DoGet event that follows I would like to be able to tell what the result was so that I can know whether or not to proceed with saving.
There may be a delay in my future responses.
UPDATE #2: I was able to find a solution. To prevent the postback from happening after clicking the "No" button. I just needed to add:
{ event.returnValue = false; return false; } // simply using return false by itself didn't help
This page really helped:
Yes, you can dynamically add a <input type="hidden" name="yes"/> tag to a form and then let the user submit the form when ready.
Or you can use Ajax--which also has the advantage of being able to work asynchronously (without necessitating an entire page refresh).
Related
I allow users to register on my website using a registration form.
Once form is submitted a token will be generated and will be sent by email to user, they need to click on the token link to activate their account.
My question is that if I do it, do the malicious codes can still send multiple emails to my website to register, should I use Captcha to protect the website or there is any other method ?
If all you want is to prevent double submissions, you can generate a unique token for the form that you check on submission. This requires some thought if there are multiple forms per page. Also, a simple method is to just disable the form/button on submission. This is even more effective if the form is submitted via Ajax (so that the action parameter of the form can be absent and thus not easily harvestable).
If you want to prevent automatic submissions (by bots), while Captcha is probably the strongest of the common methods, it is also very user-hostile. Instead, unless you have a reason to believe your site is being specifically targeted, it is usually enough to just use honey-pot fields (invisible fields that a human would never fill but a bot would) and hidden fields that you fill with a known value after a short delay using JS (a bot wouldn't normally execute JS nor take time to type into fields like a human). Simply doing an Ajax submission is also usually enough. I recommend using one or a mixture of these methods before falling back to Captcha.
Captcha is one of the standard methods.
Another way is do not do a direct submit of the form.Use AJAXfied server calls sos that form does not get posted by itself but has some data scrambling of inner fields & delays the submissions.
$("#contactForm").submit(function(event)
{
/* stop form from submitting normally */
event.preventDefault();
/* get some values from elements on the page: */
var $form = $( this ),
$submit = $form.find( 'button[type="submit"]' ),
name_value = $form.find( 'input[name="name"]' ).val(),
email_value = $form.find( 'input[name="email"]' ).val(),
phone_value = $form.find( 'input[name="phone"]' ).val(),
message_value = $form.find( 'textarea[name="message"]' ).val();
/* Send the data using post */
var posting = $.post( "contact-form-handler.php", {
name: name_value,
email: email_value,
phone: phone_value,
message: message_value
});
posting.done(function( data )
{
/* Put the results in a div */
$( "#contactResponse" ).html(data);
/* Change the button text. */
$submit.text('Sent, Thank you');
/* Disable the button. */
$submit.attr("disabled", true);
});
});</script>
I'm no expert in this matter, but the solution seems rather obvious to me:
Everyone uses CAPTCHA. There's simply no other way to protect your server from automated attack. It won't save you from DDoS, but will handle pretty much everything else because CAPTCHA is, well, CAPTCHA.
You do have multiple CAPTCHA solutions available though, so choose one that suits you best.
As Velis mentioned, easiest way is to use Captcha.
Other solutions exist but can be easily beaten if bots are targeted for your website, for example, having an hidden field like "re-enter email" which will be filled by bots, but can be caught on the server side and registration can be rejected.
Certain, complicated methods also exist, like recording mouse clicks or time taken to fill the form, but these require significant JS work and can be overkill until your website becomes a bot target.
Captcha is one plausible solution, but most humans don't like it.
How about instead if you add some intelligence to your system?
Implement a cooldown between emails. Before sending an email, wait one minute. If another email request comes then wait another minute and don't send the first one. (This could be another form of attack but only if this is the only line of defense).
Would a person try to register 30 times in the last minute? No.
Would a person re-register if the last register was successful? No.
You can also combine these with the IP of the registering user: Would a user try to create 10 new account for other users from the same IP in 10 minutes? Unlikely.
If this is a corporate website and you MUST prevent the email spamming, then consider secondary ways of communication. For example, if you have the means, you can request the user to SMS the email address to a specific number, which would create a reset password request.
You could also, upon the user completing the registration, generate a list of numbers that should be used to retrieve the account. Something like: "If your account is lost, it can be retrieved by entering one of these numbers into the RETRIEVE field" And then provide a list of numbers that would be confidential to your company and the customer. The same way Google does it.
Although these mechanisms can become complex, they will be smarter than any captcha; will be easier to adapt, and more comprehensive. On the plus side your users will thank you for not having to read twisted images of numbers and letters.
I am using spring mvc and storing some data in session. I want to delete those data when the user leave that menu and moved to next menu. I don't know where to code for it.
Also if the user is clicking other menu and if that page have any unsaved data, I want to get confirmation from the user.
Is jspDestroy() will help me for this.
Please help me.
As from the various comments above your problem is little bit clear, you want to perform some action when user is leaving the current page.
You can use unload event
window.onunload = function(){
//give ajax call here and remove whatever you want to remove from session
}
unload event
A user agent must dispatch this event when the DOM Implementation removes from the environment the resource (such as the document) or any dependent resources (such as images, style sheets, scripts). The document must be unloaded after the dispatch of this event type.
From the comments you want to remove some particular objects not all so you can use session.removeAttribute()
For removing all sessions use session.invalidate()
Is there any Listener in Java, which can detect, if the content of the page has been changed? "changed" means text in the page has been added/removed...
Process: Author modifys the page and activate it. In publish Instance it must be checked if the page content has been modified/changed
I don't think there is such listener. You're gonna have to reload/access the page or you can hook it up so when the author submits his changes you insert a value to the database that this specific page has been modified. After that you just read the data from the DB using a timer that triggers every now and then and if new line appears you do your action.
This is more of a design question and you should think about what project you're working on and what's the best approach to implement this feature.
Apache sling can handle events. There is nice tutorial here http://sling.apache.org/documentation/tutorials-how-tos/how-to-manage-events-in-sling.html .
Basically create a listener ad check if the event relates to a page node (or its subnode). Then apply whatever logic you want.
Be careful to check whether you are in an author or publish instance ( or turn off the service in author)
I am developing a spring MVC application. I ran into some interesting case.
To make it easier to explain i am taking the stackover flow buttons on the top as example( i mean those questions, tags, users, badges, unanswered buttons).
Now in my app i have similar buttons. when user clicks on any button it makes ajax call by passing proper arguments. Server makes sql queries and returns the results back.
Now assume that there is a crazy user like me who keeps on clicking those buttons without break. So each click is making a ajax call. And which ever completes its operation is showing up on front end. So even if the user clicks Tags button in the last it may show up and again the previous click on questions which took long time to return to front end can overwrite the page. How can i fix that? ( i want the tags data to be shown as it is the users last click)
In the first place i know that when user first clicks on question and then on tag i no longer need to query sql for questions button. Is there some way for me to stop processing the sql query for questions button.
Thanks
The best way to handle this is through the user interface - if the user takes some action (clicking an image) that will require significant processing on the backend, your UI should prevent other actions on the page from sending further messages to the backend until the original request is complete.
Ways to tackle this visually would be to disable/gray out other elements, make it obvious that some work is going on (with spinners, progress bars), etc.
On the server side, since each HTTP request is independent it would be cumbersome and difficult to add logic on the server to be able to detect if the user making this current request has another ongoing request currently being processed.
You probably need to take help of cookies. When the first time the action is done, write some cookie. Every time, check that cookie before you process.
You cannot simply disable a link or button from the UI and hope the user cannot do it. It can always be done in multiple ways. Additional checking is must.
(I haven't read your post completely. But from what I understand from the 1st answer...)
I had a similar problem, and I tackled it this way.
I did hand-coded ajax calls (as opposed to jQuery etc.)
I had a single global XMLHTTPRequest.
var xhr = new XMLHTTPRequest();
When the user clicked something, which needed an ajax call, I aborted the previous call, if already running.
if( xhr.readystate !=0 || xhr.readystate !=4 )
xhr.abort();
Then create a new instance of XHR, and do your business.
xhr = new XMLHTTPRequest();
xhr.open("GET", myUrl, true);
//attach callback function etc and do the send
I have done some research, and majority of the examples I have found use forms (obviously for user input) to collect data which is then passed to another JSP page through the request object.
My question is: Is it possible to pass a parameter between JSP pages if the parameter hasn't been set in HTML <form> tags?
There are a few ways to pass information from one JSP page to another.
1. Hidden values.
Simply write the data to an input field within a form with the type 'hidden', e.g.
<input type="hidden" name="mydata" value="<%=thedata%>">
Data written thus will get posted back when the relevant form is submitted. This can be a useful way to 'carry along' information as the user fills out a series of dialogs as all state is user side and the back and forward buttons will work as expected.
2. URL writing.
Attach parameters to URLs in links on the page, e.g.
<a href="another.jsp?mydata=<%=thedata>>Go!</a>
This also maintains the state with the client while removing the need for a form element to be submitted.
3. Cookies.
Should speak for itself.The state is still user side but is now handled by a cookie. More fragile in some ways since some people disable cookies. Also the back and forward buttons may do unexpected things if you are not careful
4. Server side (session)
Finally you could store the data in a session variable on one JSP and retrieve it on the next, e.g.
session.setAttribute(String key, Object value)
and
session.getAttribute(String key)
Here the state is kept server side which has some benefits (the user can browse away and return without losing his place, but tends to make the back and forward buttons in the browser a bit unreliable unless you are careful. Also the value is available to all pages.
It does however have the advantage that the information is never sent to the client and is thus more secure and more tamper proof.
There's no way a JSP page can tell the difference between a manually constructed GET url, e.g.:
Go to the next JSP page, versus something like:
<form method="get" action="/foo.jsp">
<input name="bar" value="baz">
</form>
Either way it can be accessed through getParameter or getParameterValues
Is that what you're asking?
You usually pass data between servlet/JSP or JSP pages in scoped attributes (in request, session or application). E.g. request.setAttribute("key", data) can set "key" attribute in one JSP, and request.getAttribute("key") gets you this data in other JSP (if multiple JSPs are processing same request).
It is possible to create fake parameters by wrapping your request, and overriding getParameter and similar method, if that is what you really need.
Update: my answer is talking about passing data between several parties which all process same request. This may or may not be what you want, as your question isn't clear.