Disabling pasting in text fields

Is there a way that I can easily disable pasting into a text field?

Pale H. wrote:

Is there a way that I can easily disable pasting into a text field?

Make it static text or use the disabled option. Static text would be
better.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Marnen Laibow-Koser wrote:

Make it static text or use the disabled option. Static text would be
better.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

I was wondering if it would be possible at all really. I have an email
confirmation field and wanted to disable pasting alone, not the actual
text field.

Pale H. wrote:

Marnen Laibow-Koser wrote:
I was wondering if it would be possible at all really. I have an email
confirmation field and wanted to disable pasting alone, not the actual
text field.

Here is an article that explains one way to accomplish this:

Note that this code does not appear to take care of the command key on
Macs so you might want to also watch for the Command key as well as the
Control key. I have not tested any of this code myself and I’m not sure
whether it is completely cross-platform/cross-browser or not.

Robert W. wrote:

Robert W. wrote:

Here is an article that explains one way to accomplish this:
Best Computer Products and Services – ArticlesBase.com

Of course, this will not work if the user disables JavaScript. If they
do that then I doubt there is any way to prevent someone from using
copy-paste. Unless you force them to use a custom browser or something
insane like that.

I guess what I’m saying is that, while possible, it’s probably not worth
your time doing this. Think about it this way. You’re providing the
confirmation box as a convenience to your users. It’s actually likely
that a person will mistype the same way twice than to fail once. At
least that’s true for me. If I’m typing something as common an an email
address it’s likely I’ll mistype it exactly the same way several times
in a row.

Don’t remove the convenience by adding unnecessary restrictions. People
will try find a way around them anyway. Don’t make your user have seek
for a work around for your imposed restrictions.

Maybe the “right” solution is to remove the email confirmation box
entirely then you won’t have to worry about the copy-paste issue in the
first place. Having to type something twice offers no guarantee of
correctness in the first place.

I agree in some ways. I’ve come up with a much better validation
technique anyway. There are hundreds of ways I could’ve validated this
simple form but what I’ve done is simple to implement into a template
for my other sites that have the same form. See below:

def contact_recieved
if params[:customer][:email] == params[:customer][:confirmmail] &&
params[:customer][:email].include?(“@” && “.”)
Mailer.deliver_contact_recieved(params[:customer])
redirect_to :action => ‘thank_you’
else
redirect_to :action => ‘contact’, :customer => params[:customer]
flash[:notice] = “E-Mail is required and needs to be valid.”
end
end

Your thoughts?

Pale H. wrote:
[…]

I agree in some ways. I’ve come up with a much better validation
technique anyway. There are hundreds of ways I could’ve validated this
simple form but what I’ve done is simple to implement into a template
for my other sites that have the same form. See below:

def contact_recieved
if params[:customer][:email] == params[:customer][:confirmmail] &&
params[:customer][:email].include?(“@” && “.”)

That will never return true. Do you see why?

  Mailer.deliver_contact_recieved(params[:customer])
  redirect_to :action => 'thank_you'
else
  redirect_to :action => 'contact', :customer => params[:customer]
  flash[:notice] = "E-Mail is required and needs to be valid."
end

end

Your thoughts?

The best way to validate an e-mail address is probably to send it a
message, though even that isn’t perfect.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Marnen Laibow-Koser wrote:

Pale H. wrote:
[…]

I agree in some ways. I’ve come up with a much better validation
technique anyway. There are hundreds of ways I could’ve validated this
simple form but what I’ve done is simple to implement into a template
for my other sites that have the same form. See below:

def contact_recieved
if params[:customer][:email] == params[:customer][:confirmmail] &&
params[:customer][:email].include?("@" && “.”)

That will never return true. Do you see why?

I don’t see how that won’t return true, sorry? Can you elaborate?

Robert W. wrote:

Here is an article that explains one way to accomplish this:
Best Computer Products and Services – ArticlesBase.com

Of course, this will not work if the user disables JavaScript. If they
do that then I doubt there is any way to prevent someone from using
copy-paste. Unless you force them to use a custom browser or something
insane like that.

I guess what I’m saying is that, while possible, it’s probably not worth
your time doing this. Think about it this way. You’re providing the
confirmation box as a convenience to your users. It’s actually likely
that a person will mistype the same way twice than to fail once. At
least that’s true for me. If I’m typing something as common an an email
address it’s likely I’ll mistype it exactly the same way several times
in a row.

Don’t remove the convenience by adding unnecessary restrictions. People
will try find a way around them anyway. Don’t make your user have seek
for a work around for your imposed restrictions.

Maybe the “right” solution is to remove the email confirmation box
entirely then you won’t have to worry about the copy-paste issue in the
first place. Having to type something twice offers no guarantee of
correctness in the first place.

Robert W. wrote:

Well I don’t know about the never returning true part but
…include?("@" && “.”) is going to work the way you’re thinking:

Correction: is NOT going to work…

Robert W. wrote:
[…]

Well I don’t know about the never returning true part but
…include?(“@” && “.”) is going to work the way you’re thinking:

p “@” && “.”
“.”

This will return true if the string contains a dot (.), but completely
ignores the at sign (@).

You’re right. I was thinking that the && expression just returned true,
but of course I was mistaken.

There are a lot of example of regular expressions for validating email
addresses.

And virtually all of them are incorrect. Valid e-mail addresses can
take a far wider range of forms than most people think. The only
correct regexp of this sort that I know of is about a page long.

Google for one and use one of them. I’d also recommend using
ActiveRecord’s validation support. You know that validates_format_of
thing.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Pale H. wrote:

I agree in some ways. I’ve come up with a much better validation
technique anyway. There are hundreds of ways I could’ve validated this
simple form but what I’ve done is simple to implement into a template
for my other sites that have the same form. See below:

Now we’re talking about two different things entirely. Email
confirmation field vs. email validation. I was talking strictly about
the confirmation not validation.

Marnen Laibow-Koser wrote:

def contact_recieved
if params[:customer][:email] == params[:customer][:confirmmail] &&
params[:customer][:email].include?("@" && “.”)

That will never return true. Do you see why?

Well I don’t know about the never returning true part but
…include?("@" && “.”) is going to work the way you’re thinking:

p “@” && “.”
“.”

This will return true if the string contains a dot (.), but completely
ignores the at sign (@).

There are a lot of example of regular expressions for validating email
addresses. Google for one and use one of them. I’d also recommend using
ActiveRecord’s validation support. You know that validates_format_of
thing.

Hmm, right. I’ve done some usage tests which seem to work. If the first
element of my conditions return true, it doesn’t skip the rest as you
know which means it’s performing that condition on the grounds that: the
two fields match and then that what they contain has an ‘@’ symbol AND a
‘.’ period. I don’t want any form of high level validation really. I
just want a little control.

In my mailer model I have a regexp that checks the formatting of the
email field alone (as this check wouldn’t be performed unless the
‘email’ matches the ‘confirmmail’ field on the form anyway). This means,
that if the user were to input ‘@.’ into both fields, it would call the
mailer action and deliver the view to the specified address.

However, the formatting check in the mailer would change the subject to
‘Contact form filled out (no reply email address supplied)’ and would
alter the ‘From’ field to the specified address. Anything wrong with
that?

Pale H. wrote:

Hmm, right. I’ve done some usage tests which seem to work. If the first
element of my conditions return true, it doesn’t skip the rest as you
know which means it’s performing that condition on the grounds that: the
two fields match and then that what they contain has an ‘@’ symbol AND a
‘.’ period.

No. It isn’t. Your code that you posted is not checking for the ‘@’ at
all. If your test results differ, then there’s something else going on.

I don’t want any form of high level validation really. I
just want a little control.

In my mailer model I have a regexp that checks the formatting of the
email field alone (as this check wouldn’t be performed unless the
‘email’ matches the ‘confirmmail’ field on the form anyway). This means,
that if the user were to input ‘@.’ into both fields, it would call the
mailer action and deliver the view to the specified address.

However, the formatting check in the mailer would change the subject to
‘Contact form filled out (no reply email address supplied)’ and would
alter the ‘From’ field to the specified address. Anything wrong with
that?

If @. validates, how would it know to do that?

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Marnen Laibow-Koser wrote:

Pale H. wrote:

Hmm, right. I’ve done some usage tests which seem to work. If the first
element of my conditions return true, it doesn’t skip the rest as you
know which means it’s performing that condition on the grounds that: the
two fields match and then that what they contain has an ‘@’ symbol AND a
‘.’ period.

No. It isn’t. Your code that you posted is not checking for the ‘@’ at
all. If your test results differ, then there’s something else going on.

Something else must be occurring then but if I enter ‘@.’ into the email
field. It calls the mailer action from the web controller. Therefore,
passing the check?

I don’t want any form of high level validation really. I
just want a little control.

In my mailer model I have a regexp that checks the formatting of the
email field alone (as this check wouldn’t be performed unless the
‘email’ matches the ‘confirmmail’ field on the form anyway). This means,
that if the user were to input ‘@.’ into both fields, it would call the
mailer action and deliver the view to the specified address.

However, the formatting check in the mailer would change the subject to
‘Contact form filled out (no reply email address supplied)’ and would
alter the ‘From’ field to the specified address. Anything wrong with
that?

If @. validates, how would it know to do that?

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

It doesn’t validate. It simply checks for the presence of those two
characters, not one or the other, but both; they are both mandatory
elements of an email address and therefore both must be present.

Pale H. wrote:

Marnen Laibow-Koser wrote:

Pale H. wrote:

Hmm, right. I’ve done some usage tests which seem to work. If the first
element of my conditions return true, it doesn’t skip the rest as you
know which means it’s performing that condition on the grounds that: the
two fields match and then that what they contain has an ‘@’ symbol AND a
‘.’ period.

No. It isn’t. Your code that you posted is not checking for the ‘@’ at
all. If your test results differ, then there’s something else going on.

Something else must be occurring then but if I enter ‘@.’ into the email
field. It calls the mailer action from the web controller. Therefore,
passing the check?

Yes – because it’s only checking for the period, not the @. If you try
just entering a period, I would bet money that you’d get the exact same
result.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Pale H. wrote:

Yes – because it’s only checking for the period, not the @. If you try
just entering a period, I would bet money that you’d get the exact same
result.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

So, how do I check for both?

Either two separate include? calls or a simple regex should do.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

So, how do I check for both?

Either two separate include? calls or a simple regex should do.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Thanks for your help, Marnen :slight_smile:

Yes – because it’s only checking for the period, not the @. If you try
just entering a period, I would bet money that you’d get the exact same
result.

Best,
–Â
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

So, how do I check for both?