I'm currently coding all of the account management functionality for my site, and have already implemented the account activation and password reset systems by e-mail. The e-mails each contain a link to a servlet (with the appropriate parameters attached to the end), which does all the processing. Tests for the systems have gone well, however I have one question.
If the link's text is the same as its address, is there any reason to include traditional manual activation/password reset page (a page with a form where the request parameters in the activation or reset link would be entered in to the appropriate fields)? If the link doesn't work in the e-mail, the user can always copy and paste it. Is there any particular reason why sites still have seperate pages dedicated to these actions? And should I allow it?
You never know for certain the kind of transformations your email will undergo before being displayed to the person that will eventually use your reset facility. Combined with clueless users this may pose a problem.
An example: Since reset/activation links can be quite long they may be partially wrapped onto a new line after a transformation from HTML to plain text. Inevitably this will someday happen to a user that does not know how to deal with that situation.
Therefore it might prudent to provide the backup method of just entering the code in a text field which on submit performs the GET that was intended in the first place.
You are of course free to decide that your site does not need the business of said type of user and skip implementation of the manual method!
Related
I am working with a Domestic Violence support organisation to build a website and have been asked to provide a "Quick Exit" function.
The purpose is to enable the user to exit the site quickly without closing the browser. I have seen such buttons on similar sites and the normal scenario is that they simply cause a Google search page to be shown. (easy but doesn't hide history)
I am looking for ideas to improve on this function to hide/disguise the history stored in the browser as this is currently a fairly significant flaw with the Quick Exit buttons I've seen to date.
I had a concept but I am looking for input on either fleshing out my concept, or other alternative directions to consider.
My concept was to have two domains: let's call them dv-site.com and decoy-site.com. The former being the source of domestic violence support information and the latter being some random content, could be anything, lets just say weather information for the sake of the conversation.
If a user navigates directly to dv-site.com the server redirects to decoy-site.com but also attaches some session specific, or perhaps single use query string or similar.
decoy-site.com validates the query string and, if valid, loads dv-site.com within an iframe or something like that so from the users perspective they are just looking at dv-site.com, though the domain recorded in history is decoy-site.com.
Links within the iframe loaded site would similarly be redirected with the same or a new query string.
If a user was to click on the browser history and go directly to decoy-site.com it would not be able to validate the query string and would just load the decoy site like a normal site. i.e. just showing weather information that exist on that site.
Domestic violence is a serious systemic issue and I would love some input from anyone who has more technical knowledge than I do on fleshing out this concept.
Other aspects I am unsure of how to tackle;
ensuring that dv-site.com can get crawled and ranked by search engines, even though users are all redirected, as it is imperative that it appears in search results so it can be found
technical aspects of a redirect that does not appear in history.
I'm unsure if it's possible to do this without all content and engagement being attributed to the decoy-site..
For the redirect, I believe that HTTP redirects do not get stored in history. You can use a 302 redirect for that. HTTP has a set-cookie header that lets you record a cookie - coupled with the headers here, you can give the decoy site access without recording it in history. Then, delete the cookie.
As far as pagerank goes, you could add a line to robots.txt as described here (the last point) to force the bot to scrape using a query parameter. Then in the backend, return the dv site only if that parameter is passed, otherwise redirect. If the googlebot removes query params when publishing, it will work out. Otherwise, it might fail.
Best of luck.
We have been noticing a large number (~3400) of fake signups over the last year and have not been able to determine where they are coming from. Common parameters:
They often come from weird, yet validly formatted, email address (many in the .ru TLD or from thefmail.com)
Some use cyrillic or arabic characters in their name (we are basically focused only on US English speakers by our content)
They do NOT trigger the Intercom.io javascript for account signup notifications
They somehow defeat reCaptcha 3
They sometimes use URLs for their username
They don't confirm (devise_confirmable)
We've been handling these by disabling the accounts, and there's obviously a few items above we could use to identify these before they even get created, but I was wondering if someone's cracked this nut already or if there's some simple best practices (pwned db check?) that might cut this down to a dull roar or out entirely.
The two big "I don't get its" are bypassing the JS and defeating recaptcha. Is this just mechanical-turking?
Do you know whether these users have been created by the same IP address? (probably not). Are the accounts sporadically created or are they created in batches? The gem rack-attack could be used to mitigate this issue, especially if at least one of these conditions is satisfied. It also comes with some sort of fail2ban filter which could be helpful, as it is designed to detect suspicious requests from 'misbehaving' clients.
I also can't understand how they possibly bypassed recaptcha.
I am trying to build a free web application using ruby/rails It should be able to send sms through online forms of various mobile operators. (like this one (in russian)).
So, I need to
wait for the user, who wants to send an sms through my website.
establish connection to operator website. Probably, using Mechanize.
retrieve captcha
show captcha to the user
allow user to enter a message and captcha
submit form on operators website (with message, captcha, phone number)
The connection to the operator website should be alive during all this process (otherwise captcha will change). As far as I understand, I need to create a (sub)process each time sms is sent.
Could you please advise what is the best way of handling this in rails\ruby?
I am still rather new to web-development...
Should I use threads? forks? popen? using PTY? some external gem? How should I communicate with my process?
Assuming there's nothing special about the operator's web site, no, you don't need to keep a connection alive during the whole process. Generally speaking, forms on web pages work like this: You visit the URL, your web browser downloads the page with the form on it. In your case, it will also have an <img> tag or similar to show the CAPTCHA. Once your browser has downloaded the page, the connection is severed. After you fill out the form and click on Submit, your web browser opens a new connection to the server and sends the data, and the server sends its response (whatever page is shown after you click Submit).
All your program has to do is emulate this experience. So: 1) Download the page with the form on it. Scrape the form fields (make sure you don't miss any hidden fields--with a CAPTCHA there will probably be some) and the CAPTCHA. 2) Build a page to show your user that includes the CAPTCHA and a form with all the fields they need to fill out. If there were hidden fields in the original form, make sure you include their values (as hidden fields in your form) as well, because when the user submits your form you'll need them. 3) Then, when the user submits your form, send the data, including the hidden values and what the user entered for the CAPTCHA, to the operator. 4) Finally, check if the operator indicated success, and build a page to tell your user.
If you're doing this in Rails, you'll probably have two methods in your controller: One called e.g. 'show' (steps 1 and 2 above) that will scrape the CAPTCHA and other info from the operator's site and show the user your form view, and one called e.g. 'send' (step 3 and 4 above) that the form will submit to, and which will take their data and send it to the operator's web site, collect the response and tell your user if it was successful or not.
Note: You'll want to read the operators' terms of service before you bother with any of this. I'm fairly certain that this kind of thing will be against their TOSes and if they notice your server sending a lot of requests their way they're going to block you pretty quick.
To answer another question of yours, you can use DRb or background_job (aka BJ) to actually accomplish the sending in the background so that after your user submits the captcha they don't have to wait for the response. Or you could wrap this in ajax and have the DRb/BJ process notify you when the sms sending has happened so you can notify the user of success or any problems.
Typically opening threads in Ruby is something to avoid as there are so many great gems that do what we need. Not to say that you shouldn't use threads, just that for the most part it's probably already been done really well.
I'm building a publicly available web app. Because of this, I'll be validating every field as exhaustively as I can. I mean, if someone enters something that isn't valid, they will know exactly what it was (making it clear what they need to fix).
I've followed Scott Guthrie's examples in the NerdDinner eBook. I love the idea of having all my validation in the core class files (as a partial class).
The validation I'm performing is this:
Min value - make sure strings are at least a certain length
Max value - make sure strings are under a maximum length (based on field properties in the DB)
int checks - make sure integer fields can be correctly parsed to int
file extension - make sure the uploaded file extensions are of the correct type
My question is, what are the typical validation checks you make in your web apps? Maybe I'm completely overlooking something. ;)
Thanks in advance!
You should try to use existing frameworks as much as possible for validation. Writing a comprehensive validation library is a lot of hard and time-consuming work. It's one of those things that are best left to a team of people dedicated to developing it such as the jQuery validation plugins and projects like that. There are a lot of really nice validator libraries out there already that could save you a lot of time and effort.
There is an MVC validator toolkit project on codeplex you may find helpful. CodeProject has a tutorial on it if you want to read more into it. You can also check out xVal, as one of the commenters mentioned.
If you have a specific reason you need to write validation in-house, or you aren't convinced by what I said above, a few that I find useful are:
Required field validation, obviously. You might already have this by just checking for minimum length in your fields.
Generic regular expression validation. Make sure you have some way to perform this kind of validation generically. This will help you in case there is some specific field that needs a unique form of validation found no where else in your site. Make sure your API is flexible enough to add specific regular expression based validation.
Email. You'll need this.
Phone numbers. These can be tough because of all the forms they can come in (all numeric, sometimes with alpha characters, sometimes international numbers that follow different formats)
Dates & times are important also, however you should consider using some sort of date/time picker to reduce the possibility of error by not allowing the user to type a value.
Make sure you include validation capabilities for non-textbox related fields, such as drop-down lists, radio buttons, check boxes, etc. I've forgotten these in the past just out of oversight, but they do become important.
Matching fields. For example, when confirming a password, both fields should match. This won't be used in just one page. Think about password resets, administrative pages, user control panels, etc.
Although somewhat complex, you might also want to include sequence validation. For example, perhaps some options on your site require you to select other options first. Another example is that certain options should only be selectable if you first choose some other combination of options. This is something that you may not be able to include in a generic API, but it's something to think about.
You'll want to check for SQL injection, XSS, and CSRF. You can use these tools for Firefox to help you test those. Then there are also things like making sure that the username doesn't equal the password, login throttling, etc. Validating your CSS and XHTML isn't bad either, though I don't think that's quite what you meant.
In addition to what others have mentioned, don't forget to validate items that depend on one another. That is, consistency of input values. If the user enters a maximum and a minimum, for example, don't just check the two values independently against their legal max and min, but also check them against each other to ensure that the values entered are logically consistent.
For hostnames, you may want to validate that DNS returns an IP address. If it does not, let the user know but don't necessarily reject the hostname for this reason. Maybe the user is pre-configuring something that doesn't exist yet. It depends on the specific application.
That is, in addition to syntactic validity, you can also check that the values entered are meaningful and consistent with each other.
Another thing you can do if you go all out is to only allow digits to be entered in numeric fields, only allow digits and "-" in credit card or phone number fields, and so on.
And always, always allow the user to enter input in the most familiar format, even if you later have to strip out extraneous data. For example, let the user (but don't require the user to) enter a phone number is 1-800-555-1212 even if you later strip out the "-" characters.
Not really sure what this has to do with asp.net-mvc but...
I always try to avoid over-validating (obviously you need to do the simple sanity stuff to make sure there are no db errors). It is a field by field decision according to your business rules. Some fields will need to have strict validation rules, like a credit card number. But just always think about how the validation will server the user. There is rarely a need for the regex to match all possible email addresses - it is really annoying when a site won't allow + signs in your email. In most cases, your app will be just fine if you let people put in phone numbers how they want. And always second guess yourself when you're about to put a required rule on a field.
I recommend the entlib validation application block for a easy to use and extend framework.
I have made a little app for signing up for an event. User input their data and click "sign me in".
Now sometimes people are double in the database, the exact same data that got inserted 2 times very quickly after each other. This can only mean someone clicked the button twice, which caused two posts to happen.
This is common web problem, as credit card apps and forum apps often say: "Clicking once is enough!".
I guess you could solve it by checking for the exact same data to see if the post is unique, but I wonder if there are other methods.
This ofcourse does not count for ASP.NET webforms, because POST doesn't matter as much.
While JavaScript solutions can disable the submit button after it has been clicked, this will have no effect on those people who have JavaScript disabled. You should always make things work correctly without JavaScript before adding it in, otherwise there's no point as users will still be able to bypass the checks by just disabling JavaScript.
If the page where the form appears is dynamically generated, you can add a hidden field which contains some sort of sequence number, a hash, or anything unique. Then you have some server-side validation that will check if a request with that unique value has already come in. When the user submits the form, the unique value is checked against a list of "used" values. If it exists in the list, it's a dupe request and can be discarded. If it doesn't exist, then add it to the list and process as normal. As long as you make sure the value is unique, this guarantees the same form cannot be submitted twice.
Of course, if the page the form is on is not dynamically generated, then you'll need to do it the hard way on the server-side to check that the same information has not already been submitted.
Most of the answers so far have been client-side. On the server-side, you can generate a hidden field with a GUID when you first produce the form, and then record that GUID as a submitted form when the post is received. Check it before doing any more processing.
Whenever a page is requested from the server , generate a unique requestToken , save it in server side,mark status as NOT Processed and pass it along with the current requested page. Now whenever a page submit happens , get the requestToken from the "POST"ed data and check the status and save the data or take alternate action.
Most of the banking applications use this technique to prevent double "POST"ing.So this is a time proven & reliable way of preventing double submissions.
A user-side solution is to disable the submission button via Javascript after the first click.
It has drawbacks, but I see it often used on e-commerce websites.
But, it won't never replace a real server-side validation.
Client side techniques are useful, but you may want to couple it with some server side techniques.
One way to do this is to include a unique token in the form (e.g. a GUID or similar), so that when you come to process the form you can check to see whether the token has already been used, preventing a double submission.
In your case, if you have a table with event visitors, you might include this token as a column.
A client-only solution won't be enough, as stated in many of the answers here. You need to go with a server-side fail-safe.
An often overlooked reason that disabling the submit button doesn't work is, the user can simply refresh the submit target (and click OK on the "are you sure you want to resubmit the POST data?" dialog). Or even, some browsers may implicitly reload the submitted page when you try to save the page to disk (for example, you're trying to save a hard-copy of an order confirmation).
Almost no one has js disabled.
Think about coding your e-commerce website for the 70 year old woman who double clicks every link and button.
All you want to do is add a javascript to prevent her clicking "Order Now" twice.
Yes - check this at the server side too "be defensive" - but don't code for that case. But for the sake of a better UI do it on the client side too.
Here are some scripts that I found:
//
// prevent double-click on submit
//
jQuery('input[type=submit]').click(function(){
if(jQuery.data(this, 'clicked')){
return false;
}
else{
jQuery.data(this, 'clicked', true);
return true;
}
});
and
// Find ALL <form> tags on your page
$('form').submit(function(){
// On submit disable its submit button
$('input[type=submit]', this).attr('disabled', 'disabled');
});
None of the solutions address a load-balance server.
If you have some load balancer, send a UUID (or any type of unique number) to the server to store and read again will not work well if the server is not aware of other servers, because each request could be processed by a different server in a stateless environment. These servers need to read/write to the same place.
If you have multiple servers you will need to have some shared cache (like a Redis) among the servers to read/write the unique value in the same place (what could be an over-engineering solution, but works).
Client side alteration is a common technique:
Disable submit button
Change the screen to a "please wait" screen
If the form was modal, changing the screen back to their usual process (this has the benefit of making things look really slick)
But it's not perfect. It all relies on JS being available and if that's not the case, without back-end duplication detection, you'll get duplicates still.
So my advice is to develop some sort of detection behind the scenes and then improve your form to stop people with JS being able to double-submit.
You can track the number of times the form's been submitted and compare it to the number of unique visits to the page with the form on it in the session.
Beside the many good techniques already mentioned, another simple server-side method, that has the drawback of requiring a session, is to have a session variable that is switched off on the first submit.