Does it make any sense to include a captcha when registration already requires email confirmation? any added benefit or just a waste of effort?
Neither will prevent current bots from getting into your system if that is your reason for doing these. Usually email confirmation is done to validate that the user gave a correct email address if you have need to contact them (or spam them). I don't see the value in adding a captcha to that.
Related
Is there any reason a site login needs a username/password? If an email address or cell number is supplied a text or email could be sent back at which point you would click on the link. Would this be enough to be considered authenticated by the site. Much like a password reset email/text, except you would be logedin instead.
Maybe this is not the correct forum to post this.
But, usually an username gives more sense of "ownership" / sense of belonging to an account.
Also for security reasons! I'd rather not give my personal email to everyone or in some places.
And if they already ask my email, I would imply my username is the information other users have access to, and not necessarily my email.
e.g. a Forum / Payments / etc...
I have mailto links with which I allow users to manually put the recipient's address by leaving the mailto link empty, like so:
Share
But when tested in tenon.io, it complains about the empty email address:
Do we have a workaround for this?
Karl Groves here, Founder of Tenon.
Tenon is purposefully opinionated. The goal of the product is to assist website owners in ensuring an accessible user experience. Weighing strict technical conformance vs. user experience is a constant dance. Ultimately the end user may need to choose to ignore some of our guidance.
It is true that the mailto: protocol does not require an email address. And, in the case of #qtgye's link, it is a valid use. If I was #qtgye I'd ignore Tenon's result.
However, we do consider this to be a useful test. In response to this thread, I posted a Twitter poll: https://twitter.com/karlgroves/status/869208982250024960
98% of respondents do expect an email address in a mailto: link. The reason why this is an accessibility issue is that mailto: links will open the user's email client. Users who cannot see the entire screen may assume that the email address is already filled-in on their mail client.
That being said, we do have to take into consideration the fact that the email address is not technically required. Each test in Tenon has a certainty score which, as the name implies, indicates how certain we are that it is a real issue. We will be lowering the certainty score on this test. We are tracking that adjustment as Issue TEN-2573 in our issue tracking system.
Thank you for bringing this up #qtgye
The mailto protocol does not require an addr-spec definition. So your link is valid, and this is a false negative.
I'd like to know if the following is actually possible:
A mailto link that does not contain an email address, but somehow auto populates the TO: field with the email of the original sender.
For example:
"a href="mailto:ORIGINALSENDER?subject=UNSUBSCRIBE&body=I would like to unsubscribe from future emails">Click here to send an unsubscribe email /a"
Is this possible without having to specify an email address in the link itself? Is there a class or function i can call to autopopulate the To: field?
The reason i ask is we send out curated email templates to individual customers and they are sent via a specific system. This system does not have an unsubscribe function, unfortunately. I am not able to use or suggest a system that does as i am but a lowly cog in the corporate machine.
In a word, no, not dynamically in an email that I'm aware of. Are you sending from the same email address each time? Can you set up an additional email address to handle unsubscribes and just have that hardcoded? (i.e. unsubscribe#yourdomain.com and have that monitored)
If you're using different email addresses, then consider replacing 'click here to unsubscribe' with something to the effect of 'to unsubscribe, reply to this email with unsubscribe in the subject line'
Lastly, making a recommendation and giving a good argument for using a system that better suits your requirements is a first step towards being more than a lowly cog in the corporate machine :)
Edit - migrated to ui Stack Exchange (please close this question)
Do you find it necessary/worthwhile to make a user repeat his password in a registration form, assuming that form includes an email address?
Pros: I imagine there are quite a few cases where users mistype their password in the registration form.
Cons: If you require a valid email anyway, he can always retrieve/reset his password via email - and for the users that do get the password right in the first try, this is yet-another-field-in-the-registration-form (which I prefer be as simple as possible)
I would say using the password reset functionality in place of double-entry is not horrible, but it would require a decent UI on the login page to ensure the "forgot your password" link is clear -- such as having it appear much bigger upon invalid password entry.
I'd personally go a different way: ask for the password after a 'verify your email address' message.
One thing to consider is you also need a valid email address -- so if they mis-enter their email, and also their password, their account is effectively locked. Many sites require clicking a link (and/or entering a code) upon account creation, in order to verify email address, before making the account active. If you're doing this, then there is an annoying UX thing to avoid: it's not always clear why my account doesn't work.
I've seen this personally where I enter a password during registration, but then it tells me "invalid password" when I try to login, rather than "your account is not yet activated". Minor, but an annoyance.
One way to get around this is to not ask for a password until they've clicked the link in the email, then you prompt to create a new password. You can use double-entry here, since it's the only thing on the form, and it's a pretty simple way to avoid an easy user mis-entry. Users are also quite used to this model, practically every password entry system works like this.
It also handles an additional use case, where the user themselves is not the one creating the account (not sure if this applies to you or not). Someone can create the account on the user's behalf, but then the user is still choosing their own password after clicking on the 'verify' link they get via email.
I do think that it is worthwhile - as an additional validation just to ensure that users havent mistyped the password (especially coz we cannot see the password being typed in most cases). I think it provides a sense of validation to the user as well that he is in fact sure of his password before he submits the form.
However, this is valid only in case of forms which do not allow you to copy / paste from one field to the other (I have used sites where their forms allow me to copy paste which inherently makes having the 2nd field completely useless)
Personally, however, i find it extremely irritating when a form makes me re-type my password. But i still do think that its a useful validation to have.
I've recently found a web site where the email address is included within hidden tags in a html form. Is this a bad practice and why other than the stealing of mail addresses?
It's a bad practice.
A malicious user can use a tool like Firebug to change the hidden field's content.
He can then use your form to spam or send anonymous emails, as an example.
It is an alternative in using session to store the email value for a certain purpose.
Assumably, a field called "to" contains the email address of the organization being contacted. Since this doesn't vary by customer, it shouldn't be part of the form; it should be part of the form's target script.
Even if the "to" email is somewhat variable (say a limited list of webmaster, technical service, sales, complaints dept, etc.), the form should not contain the target email. It should contain a dropdown send-to list where the option values are integers that are used by the script to determine which email address is appropriate. Aside from security concerns, an option list like the one described is easily generated from an array. So changes to your email list are easy to make.
Keeping the email address off the contact form helps prevent misappropriation of your form for spamming. And it also keeps your email address(es) private from webscrapers.
It's just a way of keeping track of the email address that must be required somewhere. Since they can't figure out by themselves your email address, I suppose that you entered it in the system before, so I wouldn't call that stealing.
As for practices, I'm not a big fan of hidden fields since they are so easy to change, but it can do the job if needed. Of course you need to have all sort of data validation on the backend treat hidden fields as if they were user inputs.
Where what email address?
The email address the form will get submitted to? It isn't very clean, but there is nothing terrible about it. (If the server side form handler doesn't check the email address against a white list then it is an invitation to spam relay, and that is terrible).
The email address the user entered on the previous page? No problems, this is just maintaining state, and it can't be stolen - only the user who entered it in the first place will get to see it. (This half of the answer removed in response to comments)