I'm using Spring MVC and have a page in my web application where I have a mailing address field that is mandatory and a radio button with a question asking 'Is the billing address the same as the mailing address?' Neither yes or no is selected by default to force the user to select an answer to the question via validation.
I have currently implemented it so that in the controller, if the radio button value is 'Yes', I copy the value of the mailing address into the billing address.
My validation works like so:
If the radio button has been set to yes then don't validate the billing address input fields, otherwise perform validation on those fields.
Is this an ok way to implement this functionality? The only other thing I could think of is to get JQuery to populate the values when the radio button is selected.
Why would you do the copying in the Java controller code versus Javascript?
I havent worked with Spring, but validation issues are aapplication wide, dispite of the framework. I've seen something in my development years, that you must know, is that validation should be performed on the server side and on the client side.
Always remember that Javascript validations can be bypassed using Firebug, or some other Mozilla plugin, but server validation is harder/almost impossible to bypass. Keep this in mind before you make the desition of leaving validation only for Javascript.
Hope I can help!
I agree with dconde, the only thing I would suggest is disabling the Billing Address fields in the UI if the user selects "Billing Address Same". This will provide concrete visible feedback that there is no need to enter values
Related
I read couple of articles regarding VIPER. So using the knowledge i got from it, i have build an sample app using viper architecture for my login Activity. In this activity i have 2 Edittexts (username and password) and one button. Once the user click the login button i need to validate the username and password if its not null, if it is null i should show an error message asking the user to input data.
My question is, where can I put my Editext validation code?
Which VIPER module handles that job?
As described in
https://theswiftdev.com/the-ultimate-viper-architecture-tutorial
the presenter zone is where "business logic" gets implemented in a non-UI way. There would be 2 kinds of validation of input events:
valid to the "business"/backend-engineering-infrastructure requirements versus
valid to the constraints of the UI (e.g., within bounds of some perimeter)
The content of an edit-textual field is almost always in category #1. Hence the content of the edited textual field would eventually make its way to the presenter zone for validation of whether, say, the password conforms to minimum complexity requirements for good-enough security.
I'm currently trying to extend the Liferay create account process so the user gets asked to provide his or hers telephone number and address during registration.
I know that Liferay supports the concepts of custom fields and I have managed to add them to the registration form and persist them to the database. However, out of the box, Liferay has support for phone numbers and addresses to be associated with an user account. I don't think it is a sound development technique to use custom fields for something that is already there.
Anyways my question is, what is the preferred technique to ask for an address and/or a phone number during registration? I tried hooking to the Struts registration action but I don't think that is the solution, in order to use the PhoneLocalService ot AddressLocalService I need a user ID and I get the user ID after I add the user to the database.
I admit hooking and extending Liferay is a bit of a mess for me right now, so any advice will be appreciated.
Unfortunately, the standard customization is quite limited (with a few properties you can turn on-off some features, like the captcha, or the prefix-postfix titles, etc., but nothing complicated).
The only way to customize registration JSP and the contacts JSP, mix them up and put it into the hook as the registration form.
I have done the exactly same thing as you need here, and I must say the handling of addresses and phones is a complete mess on first sight (it is done with auto forms, because you can have multiple ones). After throwing out the unnecessary code though it is quite straightforward to include a fix number of phone/address on the registration form.
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.
Assuming I have a web app (Java EE 6), I want to realize the following use case:
On a generic "register" page, user enters his/her email and submits
System sends email to user. In this mail, there should be a link to a full registration page
User follows link, fills out required credentials, and submits
System stores user in database, and sends confirmation email
All temporary data is discarded.
The part I am having problems with is mostly step 2. What I need to know is the following:
What is the best way of setting up a personal registration page for the user? Should I generate a temporary page and link to it? Should I give the user a special cookie? In either case, how can I implement this? No code is needed, I just need some pointers on where to start looking and coding.
EDIT:
A very important question here, no matter how I do it, is the following: How can I generate and deploy a temporary webpage? I am rather new to Java EE, so forgive me if this has an obvious answer.
If the registration page is standard for every user then there is no need in creating a temporary page and linking to it or creating a special cookie etc... Just create the page with the registration form on it and send your clients a link to that.
If you want a special customized registration page for a specific user, then you can just send an e-mail with a link to your client with their information as a query parameter (ie http://yoursite.com/registration?fname=jordan&lname=denison) or you could use something like PrettyFaces to make the URL more readable as well as making it easier to extract those parameters and fire a method with them.
If I had to do it, then I would have
Created a generic registration page
Created a unique ID for the user
Send the link to user which contains the unique ID as a parameter
The registration page throws error if the unique ID is not presented to it, or the ID is not valid (already used, or not issued)
A good design solution when a form is submitted, what should be the behavior of "back" and then "forward" browser button.
Similar question is what should happen when a user logout an application the then click "forward" browser button?
I will be glad to hear some scenarios for the mentioned situations.
Thanks.
Edit - should be good to share and my point of view :-)
My personal opinion is after logout the user should be not able to enter the application without go through the login page.
For the submit scenario - after submitted and back browser button , the user should be able to return to the form but with NO containing data.
One common pattern is Post/Redirect/Get. Under that pattern, the result of the post is a bookmarkable (and back/forward navigable) page. The Back button has one of it usual meanings of "I didn't mean to go here, take me back where I was" like hitting ESC in most Windows dialogs, and the Forward button means "I didn't mean to hit the back button, I wanted that page after all." This pattern isn't going to work for everyone; it makes the most sense when each page (including the response to a form submit) represents some conceptual entity that you'd want to bookmark.
As for the logout scenario, most apps check whether you're logged in no matter what page is specified in the URL, and redirect to the login form if you're not logged in. (You don't have to code that on every page; the check is usually a Valve or something.) A nice feature is to remember where the user was trying to go and take them there upon sucessful login.
Your question is more about design than technology, so GWT doesn't really change the picture, except to note that the GWT history mechanism is intended to mimic the behavior of static pages connected by links, which the post/redirect/get pattern does also.
It is very common to use state machines to keep the user(session) and request state. If you have such a state machine then you know that user is trying a wrong transition. Depending on the user state and the wrong transition you can forward the user to a page. For example if the user tries to go to a page which needs to be logged in but she/he has already logged out, you can send her/him to a login page but you can provide user name and only ask for the password.
To add this functionality you can write your own code by hard-coding the state machine in your code or you can use one of the available libraries. For example,
Spring Web Flow provides this functionality for Spring framework.