Related
When you have saved username and password for some site Chrome will autofill that username and password, but if you try to get the value for the password input field it is empty String even though there is value there ******.
If you click somewhere on the page no mater where the value of the input type="password" will be filled.
This is Fiddle user/pass of the structure of the html and the console.log command. It cannot be seen here but it can be reproduced on every page that has login form and the username and password are autofilled on the load of the page. If you inspect the value of the field before clicking anywhere else on the site it will be empty String.
This is not the case in Firefox or Internet Explorer it will fill the value of the input element with the password.
I am using Windows 7 Ultimate 64-bit OS and Google Chrome version is 48.0.2564.97 m
Is this normal behavior, bug or?
UPDATE:
If you click on F5 to reload the page and inspect the password field the value for password will be there. If you click the reload button in Chrome in top left corner the value for the password field will be empty string.
This seems to be a bug in Chrome. When Chrome auto-fills a password on an initial page load (but not a refresh), the value appears in the form field on-screen, but querying passwordField.value in Javascript returns an empty string. If you depend on seeing that value in Javascript, this prevents you from doing so. Once the user does any other action on the page, such as clicking anywhere on the page, the value suddenly becomes visible to Javascript.
I'm not actually 100% sure if this is a bug, or if there is a security reason for doing this such as preventing a hidden frame from stealing your password by tricking the browser into filling it in.
A workaround that we have used is to detect the background color change that Chrome makes to fields that it has auto-filled. Chrome colors the background of auto-filled fields yellow, and this change is always visible to Javascript even when the value is not. Detecting this in Javascript lets us know that the field was auto-filled with a value, even though we see the value as blank in Javascript. In our case, we have a login form where the submit button is not enabled until you fill in something in the password field, and detecting either a value or the auto-fill background-color is good enough to determine that something is in the field. We can then enable the submit button, and clicking the button (or pressing enter) instantly makes the password field value visible to Javascript because interacting with the page fixes the problem, so we can proceed normally from there.
Working Answer as of July 8, 2016
Adam correctly stated this is a bug (or intended behavior). However, none of the previous answers actually say how to fix this, so here is a method to force Chrome to treat the autocompleted value as a real value.
Several things need to happen in order, and this needs to only run in Chrome and not Firefox, hence the if.
First we focus on the element. We then create a new TextEvent, and run initTextEvent, which adds in a custom string that we specify (I used "#####") to the beginning of the value. This triggers Chrome to actually start acting like the value is real. We can then remove the custom string that we added, and then we unfocus.
Code:
input.focus();
var event = document.createEvent('TextEvent');
if ( event.initTextEvent ) {
event.initTextEvent('textInput', true, true, window, '#####');
input.dispatchEvent(event);
input.value = input.value.replace('#####','');
}
input.blur();
Edit August 10, 2016
This only works right now in Chrome on Windows and Android. Doesn't work on OSX. Additionally, it will stop working at all in Sept 2016, according to:
https://www.chromestatus.com/features/5718803933560832
Also, I've opened a Chromium ticket.
https://bugs.chromium.org/p/chromium/issues/detail?id=636425
As of August 12, a member of the Chrome team said on the above ticket that the behavior won't be changing because they don't consider it a bug.
Long-term Work-Around Suggestion:
That said, the current behavior has been tweaked from when it was first implemented. The user no longer has to interact with the password input for the value to be reported. The user now just needs to interact (send a mouse or keyboard event) with any part of the page. That means that while running validation on pageload still won't work, clicking on a submit button WILL cause Chrome to correctly report the password value. The work-around then, is to revalidate all inputs that might be autocompleted, if that is what you are trying to do, on submit.
Edit December 13, 2016:
A new Chromium ticket has been opened and is being received better. If interested in changing this behavior of Chrome's, please star this new ticket:
https://bugs.chromium.org/p/chromium/issues/detail?id=669724
Continuing from what Kelderic said, here's my work around. Like a lot of people, I don't need the actual password value. I really just need to know that the password box has been autofilled, so that I can display the proper validation messages.
Personally, I would not use suggested solution to detect the background color change cause by Chrome's autofill. That approach seems brittle. It depends on that yellow color never changing. But that could be changed by an extension and be different in another Blink based browser (ie. Opera). Plus, there's no promise Google wont use a different color in the future. My method works regardless of style.
First, in CSS I set the content of the INPUT when the -webkit-autofil pseudo-class is applied to it:
input:-webkit-autofill {
content: "\feff"
}
Then, I created a routine to check for the content to be set:
const autofillContent = `"${String.fromCharCode(0xFEFF)}"`;
function checkAutofill(input) {
if (!input.value) {
const style = window.getComputedStyle(input);
if (style.content !== autofillContent)
return false;
}
//the autofill was detected
input.classList.add('valid'); //replace this. do want you want to the input
return true;
}
Lastly, I polled the input to allow the autofill time to complete:
const input = document.querySelector("input[type=password]");
if (!checkAutofill(input)) {
let interval = 0;
const intervalId = setInterval(() => {
if (checkAutofill(input) || interval++ >= 20)
clearInterval(intervalId);
}, 100);
}
It is amazing that in 2021 this has not been solved in Chrome yet, I have had issue with autocomplete since 2014 and still nothing.
Chrome functionality autocomplete is misleading for the user, I do not know what are they trying to achieve but does not look good.
As it is now, form appears showing auto-completed text (user/email/pass) to the user, but in the background html - values are not inside of the elements.
As values are not in fields custom validation will disable submit button.
Script that checks fields values will say value is null, which is even more confusing for the user as s/he can see text is there, and can assume it is valid, leading to confusing delete-one insert one character. (Embarrassingly, I have to admit I did not know that you need to click in the body of the HTML, so I wonder how many users don not know the same)
In my case I wanted to have empty field always and then fount out it is just needlessly spent time to make it work.
If we try autocomplete=off we will discover that it is not working. And to validate fields and let say enable button we need to do some trickery.
(Have in mind that I have tried autocomplete=password new-password) and other type of Hocus-Pocus trickery from official resource.
At the end I have done this.
<script>
$('#user').value = ' '; //one space
$('#pass').value = ' '; // one space - if this is empty/null it will autopopulate regardless of on load event
window.addEventListener('load', () => {
$('#user').value = ''; // empty string
$('#pass').value = ''; // empty string
});
</script>
So, it will blink for a split second in some cases in password field with * not ideal but :/ ...
Here's my solution to this issue:
$(document).ready(function(){
if ( $("input:-webkit-autofill").length ){
$(".error").text("Chrome autofill detected. Please click anywhere.");
}
});
$(document).click(function(){
$(".error").text("");
});
Basically, clicking makes the input visible to the user, so I ask the user to click and when they do, I hide the message.
Not the most elegant solution but probably the quickest.
$(document).ready
does not wait for autofill of browser, it should be replaced by
$(window).on("load", checkforAutoFill())
Another option as of Dec. 16 / Chrome 54
I can't get the value of the password field, but, after "a short while", I can get the length of the password by selecting it, which is sufficient for me to enable the submit button.
setTimeout(function() {
// get the password field
var pwd = document.getElementById('pwd');
pwd.focus();
pwd.select();
var noChars = pwd.selectionEnd;
// move focus to username field for first-time visitors
document.getElementById('username').focus()
if (noChars > 0) {
document.getElementById('loginBtn').disabled = false;
}
}, 100);
The workaround specified by Adam:
... detect the background color change that Chrome makes to fields that it has auto-filled. Chrome colors the background of auto-filled fields yellow, and this change is always visible to Javascript even when the value is not. Detecting this in Javascript lets us know that the field was auto-filled with a value, even though we see the value as blank in Javascript
I did like this:-
getComputedStyle(element).backgroundColor === "rgb(250, 255, 189)"
where rgb(250, 255, 189) is the yellow color Chrome applies to auto filled inputs.
I have found a solution to this issue that works for my purposes at least.
I have a login form that I just want to hit enter on as soon as it loads but I was running into the password blank issue in Chrome.
The following seems to work, allowing the initial enter key to fail and retrying again once Chrome wakes up and provides the password value.
$(function(){
// bind form submit loginOnSubmit
$('#loginForm').submit(loginOnSubmit);
// submit form when enter pressed on username or password inputs
$('#username,#password').keydown(function(e) {
if (e.keyCode == 13) {
$('#loginForm').submit(e);
return false;
}
});
});
function loginOnSubmit(e, passwordRetry) {
// on submit check if password is blank, if so run this again in 100 milliseconds
// passwordRetry flag prevents an infinite loop
if(password.value == "" && passwordRetry != true)
{
setTimeout(function(){loginOnSubmit(e,true);},100);
return false;
}
// login logic here
}
Just wrote an angular directive related to this. Ended up with the following code:
if ('password' == $attrs.type) {
const _interval = $interval(() => { //interval required, chrome takes some time to autofill
if ($element.is(':-webkit-autofill')) { //jQuery.is()
//your code
$interval.cancel(_interval);
}
}, 500, 10); //0.5s, 10 times
}
ps: it wont detect 100% of the times, chrome might take longer than 5 seconds to fill the input.
Chrome's intended behavior is that an auto-filled password has an empty value in the DOM until the user interacts with the frame in some way, at which point chrome actually populates the value. Until this point any client side validation or attempt to ajax submit the form will see the password as empty.
This 'populate password value on frame interaction' behavior is inconsistent. I've found when the form is hosted in a same-origin iframe it only operates on the first load, and never on subsequent loads.
This is most evident on ajax forms where the autocomplete password populates on first load, however if that password is invalid and the ajax submission re-renders the form DOM, the autocompleted password re-appears visually but the value is never populated, irrespective of interaction.
None of the workarounds mentioned such as triggering blur or input events worked in this scenario. The only workaround I've found is to reset the password field value after the ajax process re-renders the form, e.g.:
$('input[type="password"]').val("");
After the above, Chrome actually autocompletes the password again but with the value actually populated.
In my current use case I'm using ASP.NET's Ajax.BeginForm and use the above workaround in the AjaxOptions.OnSuccess callback.
$element.is("*:-webkit-autofill")
works for me
With Angular, the new behaviour in Chrome (only allowing autofilled values to be read after the user has interaction with the page) manifests itself as an issue when you're using Angular's validation functionality in certain scenarios (for e.g using standard method/action attributes on the form). As the submit handler is executed immediately, it does not allow the form validators to capture the autofilled values from Chrome.
A solution I found for this to explicitly call the form controllers $commitViewValue function in the submit handler to trigger a revalidation before checking form.$valid or form.invalid etc.
Example:
function submit ($event) {
// Allow model to be updated by Chrome autofill
// #see http://stackoverflow.com/questions/35049555/chrome-autofill-autocomplete-no-value-for-password
$scope.loginModule.$commitViewValue();
if ($scope.loginModule.$invalid) {
// Disallow login
$scope.loginModule.$submitted = true;
$event.preventDefault();
} else {
// Allow login
}
}
Although this is working for us so far, I would be very interested if someone has found another, more elegant work around for the issue.
var txtInput = $(sTxt);
txtInput.focus();
txtInput.select();
This solution worked in my case.
Using jQuery 3.1.1.
If you want make input to be seen as fulfilled, try to trigger blur on it:
$('input[type="password"]').blur();
The autocomplete feature has successfully disabled.
It Works!
[HTML]
<div id="login_screen" style="min-height: 45px;">
<input id="password_1" type="text" name="password">
</div>
[JQuery]
$("#login_screen").on('keyup keydown mousedown', '#password_1', function (e) {
let elem = $(this);
if (elem.val().length > 0 && elem.attr("type") === "text") {
elem.attr("type", "password");
} else {
setTimeout(function () {
if (elem.val().length === 0) {
elem.attr("type", "text");
elem.hide();
setTimeout(function () {
elem.show().focus();
}, 1);
}
}, 1);
}
if (elem.val() === "" && e.type === "mousedown") {
elem.hide();
setTimeout(function () {
elem.show().focus();
}, 1);
}
});
To me none of this solutions seemed to work.
I think this is worth mentioning that if you want to use it for CSS styling you sould use -webkit-autofill property like this:
input:-webkit-autofill~.label,
input:-webkit-autofill:hover~.label,
input:-webkit-autofill:focus~.label
input:focus~.label,
input:not(.empty)~.label {
top: -12px;
font-size: 12px;
color: rgba(0, 0, 0, .4);
font-weight: 600
}
My solution comparing my css to the chrome autocomplete color...
$('input, select, textarea').each(function(){
var inputValue = $(this).val();
if ( inputValue != "" || $(this).css("background-color") != "rgba(255, 255, 255, 0)") {
$(this).parents('.form-group').addClass('focused');
}
});
I tried all the solutions and wasn't working for me so i came up with this.
My problem is i have an input that move the placeholder top when it is filled, off course this is not working when Chrome autofill it.
Only tested in Chrome :
setTimeout(function () {
var autofilled = document.querySelectorAll('input:-webkit-autofill');
for (var i = 0; i < autofilled.length; i++) {
Do something with your input autofilled
}
}, 200);
My version is 95.0.4638.69
I'm facing a similar issue and I solved it by changing my form's name from "login-form" to another name which does not mean anything and solve it. Reason why I didn't remove name attribute is because if I remove name attribute Chrome will look up to id attribute and do the same thing.
Option using onanimationstart event (ReactJs) - Mar 22
I could avoid the needing of verifying periodically if the input was autofilled, as described above using setInterval, by taking advantage of the onanimationstart event. I don't know if it will work in every case, but definitely did the trick for me.
I'll provide a code sample in ReactJs, it may be explanatory enough to be transposed to another context.
First of all, is necessary to add in your input the onAnimationStart property, in such a way that the event is passed as parameter to your function, as following below.
<input
className={componentClass}
placeholder={placeholder}
onChange={handleChange}
onFocus={onFocus}
onMouseEnter={onHover}
onMouseLeave={onHover}
onBlur={onBlur}
disabled={disabled}
name={name}
value={value}
onAnimationStart={e => this.onAnimationStart(e)}
/>
Then let's proceed to the onAnimationStart function body.
onAnimationStart(event) {
// on autofill animation
if (event.animationName === 'onAutoFillStart') {
event.target?.labels[0].classList.add('grm-form__isAutofilled');
}
}
First I verified if the animation name was actually the auto-fill animation, and then I added a class to the first label of my input, this is my use case but can be adapted to solve different problems.
Just set the autocomplete attribute to username for the username field and new-password for the password field;
<input type="text" id="username" autocomplete="username">
<input type="password" id="password" autocomplete="new-password" >
You mentioned:
If you click somewhere on the page no matter where the value of the input type="password" will be filled.
Which is why I simply use $('body').click(); to simulate this first click, after which the value is available in JavaScript.
Also, I set autocomplete="new-password" on my signup form password field, so that the field is not autofilled and users have to fill in a new password.
See this Google Developers page for more information.
It's not a bug. It's a security issue. Imagine if one could just use javascript to retrieve autofilled passwords without the users' acknowledgment.
I'm working on a web app and users sometimes paste in things they've copy/pasted from other places and that input may come with the character (0xAD). I don't want to filter it out, I simply need the user to see that there is an invisible character there, so they have no surprises later.
Does anyone know a way to make the always be visible? To show a hyphen, rather than remain hidden? I suspect a custom web font might be needed, if so, does anyone know of a pre-existing one?
You would need to either use JavaScript or a custom typeface that has a visible glyph for the soft-hyphen character. Given the impracticalities of working with typefaces for the web (and burdening the user with an additional hundred-kilobyte download) I think the JavaScript approach is best, like so:
document.addEventListener("DOMContentLoaded", function(domReadyEvent) {
var textBoxes = document.querySelectorAll("input[type=text]");
for(var i=0;i<textBoxes.length;i++) {
textBoxes[i].addEventListener("paste", function(pasteEvent) {
var textBox = pasteEvent.target;
textBox.value = textBox.value.replace( "\xAD", "-" );
} );
}
} );
Tumblr is really impressive in the sense that it allows users to customize their profiles and such. You're allowed to edit the HTML and CSS of your profile.
This is something I want to apply to my own site. However, I'm sure that this will be a big burden on security.
Does anyone have any tips or precautions for a feature like Tumblr's? Also, is it advisable to store the editable HTML and CSS in a database? Thank you :D
P.S.
What about server-side scripting? Lets say I wanted to grant the option of allowing the user to script a button that does something to the database. Any thoughts on how to do this?
This is a very difficult thing to get right, in my experience, if you want users to be able to use absolutely all of HTML/CSS. What you could do, however, is strip all CSS and HTML attributes, and only put "safe" code on a whitelist.
Examples
<p>This is legal code.</p>
<p><a onload="alert('XSS!')">The attribute should be filtered out</a></p>
<p>This is a legal link.
Of course you should still sanitize the href attribute!</p>
<h1>This is bad, because the rest of the page is going to huge,
so make sure there's a closing tag
<style>
.blue {
color: #00f; // keep this (by whitelist)
strange-css-rule: possibly-dangerous; // Filter this out!
}
</style>
Those are just some of the pitfalls you can encounter, though.
I'm not familiar with Tumblr, but I'm pretty sure they're doing something similar to this.
As for the database question, of course you can store HTML and CSS in a database, many systems do this. In your case, you would just need one representation anyway, anything else would just confuse the user ("Why is my CSS rule not applied; it's right there in the code!")
If you are using php then, for database issue you can use mini API system. For example, you want user to allow comment on something and save it in your database, then you can use API like this.
First, api.php file, (URL Location: http://yoursite.com/api.php)
<?php
// ID and Key can be different for all users.
// id = 1234
// key = 'secret_key'
// function = name of the function, user can call
// option = parameter passed to the function
// Now check if id, key, function and option are requested and then
// call function if it exists.
if(isset($_GET['id'], $_GET['key'], $_GET['function'], $_GET['option']) {
$id = $_GET['id'];
$key = $_GET['key'];
if($id == '1234' && $key == 'secret_key') {
// define all functions here
function make_comment($option) {
...code for saving comment to database...
}
if(function_exists($_GET['function'])) {
$_GET['function']($_GET['option']);
}
}
}
?>
Then uesr can call this function from any button using simple call to the API, like
<a href='http://yoursite.com/api.php?id=1234&key=secret_key&function=make_comment&option=i_am_comment'></a>
I'm looking for a clean way to implement the infamous "select all" checkbox, but I'd prefer a JavaScript-free solution. Does anyone know if there is a way to do that?
Thank you in advance
While it is possible to achieve part of this functionality without the use of JavaScript, I wouldn’t recommend it as it doesn’t work in older browsers.
You could use the CSS3 :target pseudo-class to toggle between different <form>s in your markup. Demo: http://jsfiddle.net/mathias/kFH3e/
As you can see, it doesn’t really “toggle” the checkboxes, but just the forms; and if you’ve already checked some boxes in one of the form it will still be checked after you switch back and forth.
This is one of the cases where it’s perfectly acceptable to use JavaScript, as the “select all/none” buttons only enhance the UI; it’s still an acceptable experience without them.
TL;DR It’s okay to use JavaScript in this case.
Unfortunately there is no way to select all checkboxes without some scripting. HTML is a static language and cannot manipulate itself in any way without a request being sent. You will need to implement javascript to utilize a select all box. you can use one of the following two:
JQUERY
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js" type="text/javascript"></script>
function toggleChecked(status) {
$(".checkbox").each( function() { // if checkboxs have class
$(this).attr("checked",status);
})
}
Javascript
function selectToggle(toggle, form) {
var myForm = document.forms[form];
for( var i=0; i < myForm.length; i++ ) {
if(toggle) {
myForm.elements[i].checked = "checked";
}
else {
myForm.elements[i].checked = "";
}
}
}
client-side solution
Need to use javascript to when a checkbox checked check rest
server-side solution
Need to reload page
when a link clicked reload page with all checkbox tags checked in php
Example for server-side solution
if (isset($_GET['selectall'](){
$check_status = " checked";
else {
$check_status = "";
}
for ($i=0;$i<100;$i++){
/* Line Codes */
print "<input type=\"checkbox\" name="\checkname\" $check_status>";
/* Rest Codes */
}
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 1 year ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
When placing email addresses on a webpage do you place them as text like this:
joe.somebody#company.com
or use a clever trick to try and fool the email address harvester bots? For example:
HTML Escape Characters:
joe.somebody#company.com
Javascript Decrypter:
function XOR_Crypt(EmailAddress)
{
Result = new String();
for (var i = 0; i < EmailAddress.length; i++)
{
Result += String.fromCharCode(EmailAddress.charCodeAt(i) ^ 128);
}
document.write(Result);
}
XOR_Crypt("êïå®óïíåâïäùÀãïíðáîù®ãïí");
Human Decode:
joe.somebodyNOSPAM#company.com
joe.somebody AT company.com
What do you use or do you even bother?
Working with content and attr in CSS:
.cryptedmail:after {
content: attr(data-name) "#" attr(data-domain) "." attr(data-tld);
}
<a href="#" class="cryptedmail"
data-name="info"
data-domain="example"
data-tld="org"
onclick="window.location.href = 'mailto:' + this.dataset.name + '#' + this.dataset.domain + '.' + this.dataset.tld; return false;"></a>
When javascript is disabled, just the click event will not work, email is still displayed.
Another interesting approach (at least without a click event) would be to make use of the right-to-left mark to override the writing direction. more about this: https://en.wikipedia.org/wiki/Right-to-left_mark
This is the method I used, with a server-side include, e.g. <!--#include file="emailObfuscator.include" --> where emailObfuscator.include contains the following:
<!-- // http://lists.evolt.org/archive/Week-of-Mon-20040202/154813.html -->
<script type="text/javascript">
function gen_mail_to_link(lhs,rhs,subject) {
document.write("<a href=\"mailto");
document.write(":" + lhs + "#");
document.write(rhs + "?subject=" + subject + "\">" + lhs + "#" + rhs + "<\/a>");
}
</script>
To include an address, I use JavaScript:
<script type="text/javascript">
gen_mail_to_link('john.doe','example.com','Feedback about your site...');
</script>
<noscript>
<em>Email address protected by JavaScript. Activate JavaScript to see the email.</em>
</noscript>
Because I have been getting email via Gmail since 2005, spam is pretty much a non-issue. So, I can't speak of how effective this method is. You might want to read this study (although it's old) that produced this graph:
Have a look at this way, pretty clever and using css.
CSS
span.reverse {
unicode-bidi: bidi-override;
direction: rtl;
}
HTML
<span class="reverse">moc.rehtrebttam#retsambew</span>
The CSS above will then override the reading direction and present the text to the user in the correct order.
Hope it helps
Cheers
Not my idea originally but I can't find the author:
<a href="mailto:coxntact#domainx.com"
onmouseover="this.href=this.href.replace(/x/g,'');">link</a>
Add as many x's as you like. It works perfectly to read, copy and paste, and can't be read by a bot.
I generally don't bother. I used to be on a mailing list that got several thousand spams every day. Our spam filter (spamassassin) let maybe 1 or 2 a day through. With filters this good, why make it difficult for legitimate people to contact you?
Invent your own crazy email address obfuscation scheme. Doesn't matter what it is, really, as long as it's not too similar to any of the commonly known methods.
The problem is that there really isn't a good solution to this, they're all either relatively simple to bypass, or rather irritating for the user. If any one method becomes prevalent, then someone will find a way around it.
So rather than looking for the One True email address obfuscation technique, come up with your own. Count on the fact that these bot authors don't care enough about your site to sit around writing a thing to bypass your slightly crazy rendering-text-with-css-and-element-borders or your completely bizarre, easily-cracked javascript encryption. It doesn't matter if it's trivial, nobody will bother trying to bypass it just so they can spam you.
I think the only foolproof method you can have is creating a Contact Me page that is a form that submits to a script that sends to your email address. That way, your address is never exposed to the public at all. This may be undesirable for some reason, but I think it's a pretty good solution. It often irks me when I'm forced to copy/paste someone's email address from their site to my mail client and send them a message; I'd rather do it right through a form on their site. Also, this approach allows you to have anonymous comments sent to you, etc. Just be sure to protect your form using some kind of anti-bot scheme, such as a captcha. There are plenty of them discussed here on SO.
You can protect your email address with reCAPTCHA, they offer a free service so people have to enter a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) to see your email: https://www.google.com/recaptcha/admin#mailhide
I've written an encoder (source) that uses all kinds of parsing tricks that I could think of (different kinds of HTML entities, URL encoding, comments, multiline attributes, soft hyphens, non-obvious structure of mailto: URL, etc)
It doesn't stop all harvesters, but OTOH it's completely standards-compliant and transparent to the users.
Another IMHO good approach (which you can use in addition to tricky encoding) is along lines of:
<a href="mailto:userhatestogetspam#example.com"
onclick="this.href=this.href.replace(/hatestogetspam/,'')">
If you have php support, you can do something like this:
<img src="scriptname.php">
And the scriptname.php:
<?php
header("Content-type: image/png");
// Your email address which will be shown in the image
$email = "you#yourdomain.com";
$length = (strlen($email)*8);
$im = #ImageCreate ($length, 20)
or die ("Kann keinen neuen GD-Bild-Stream erzeugen");
$background_color = ImageColorAllocate ($im, 255, 255, 255); // White: 255,255,255
$text_color = ImageColorAllocate ($im, 55, 103, 122);
imagestring($im, 3,5,2,$email, $text_color);
imagepng ($im);
?>
I know my answer won't be liked by many but please consider the points outlined here before thumbing down.
Anything easily machine readable will be easily machine readable by the spammers. Even though their actions seem stupid to us, they're not stupid people. They're innovative and resourceful. They do not just use bots to harvest e-mails, they have a plethora of methods at their disposal and in addition to that, they simply pay for good fresh lists of e-mails. What it means is, that they got thousands of black-hat hackers worldwide to execute their jobs. People ready to code malware that scrape the screens of other peoples' browsers which eventually renders any method you're trying to achieve useless. This thread has already been read by 10+ such people and they're laughing at us. Some of them may be even bored to tears to find out we cannot put up a new challenge to them.
Keep in mind that you're not eventually trying to save your time but the time of others. Because of this, please consider spending some extra time here. There is no easy-to-execute magic bullet that would work. If you work in a company that publishes 100 peoples' e-mails on the site and you can reduce 1 spam e-mail per day per person, we're talking about 36500 spam emails a year. If deleting such e-mail takes 5 seconds on average, we're talking about 50 working hours yearly. Not to mention the reduced amount of annoyance. So, why not spend a few hours on this?
It's not only you and the people who receive the e-mail that consider time an asset. Therefore, you must find a way to obfuscate the e-mail addresses in such way, that it doesn't pay off to crack it. If you use some widely used method to obfuscate the e-mails, it really pays off to crack it. Since as an result, the cracker will get their hands on thousands, if not tens or hundreds of thousands of fresh e-mails. And for them, they will get money.
So, go ahead and code your own method. This is a rare case where reinventing the wheel really pays off. Use a method that is not machine readable and one which will preferably require some user interaction without sacrificing the user experience.
I spent some 20 minutes to code off an example of what I mean. In the example, I used KnockoutJS simply because I like it and I know you won't probably use it yourself. But it's irrelevant anyway. It's a custom solution which is not widely used. Cracking it won't pose a reward for doing it since the method of doing it would only work on a single page in the vast internet.
Here's the fiddle: http://jsfiddle.net/hzaw6/
The below code is not meant to be an example of good code. But just a quick sample of code which is very hard for machine to figure out we even handle e-mails in here. And even if it could be done, it's not gonna pay off to execute in large scale.
And yes, I do know it doesn't work on IE = lte8 because of 'Unable to get property 'attributes' of undefined or null reference' but I simply don't care because it's just a demo of method, not actual implementation, and not intended to be used on production as it is. Feel free to code your own which is cooler, technically more solid etc..
Oh, and never ever ever name something mail or email in html or javascript. It's just way too easy to scrape the DOM and the window object for anything named mail or email and check if it contains something that matches an e-mail. This is why you don't want any variables ever that would contain e-mail in it's full form and this is also why you want user to interact with the page before you assign such variables. If your javascript object model contains any e-mail addresses on DOM ready state, you're exposing them to the spammers.
The HTML:
<div data-bind="foreach: contacts">
<div class="contact">
<div>
<h5 data-bind="text: firstName + ' ' + lastName + ' / ' + department"></h5>
<ul>
<li>Phone: <span data-bind="text: phone"></span></li>
<li>E-mail <span data-bind="visible: $root.msgMeToThis() != ''"><input class="merged" data-bind="value: mPrefix" readonly="readonly" /><span data-bind="text: '#' + domain"></span></span></li>
</ul>
</div>
</div>
</div>
The JS
function ViewModel(){
var self = this;
self.contacts = ko.observableArray([
{ firstName:'John', mPrefix: 'john.doe', domain: 'domain.com', lastName: 'Doe', department: 'Sales', phone: '+358 12 345 6789' },
{ firstName:'Joe', mPrefix: 'joe.w', domain: 'wonder.com', lastName: 'Wonder', department: 'Time wasting', phone: '+358 98 765 4321' },
{ firstName:'Mike', mPrefix: 'yo', domain: 'rappin.com', lastName: 'Rophone', department: 'Audio', phone: '+358 11 222 3333' }
]);
self.msgMeToThis = ko.observable('');
self.reveal = function(m, e){
var name = e.target.attributes.href.value;
name = name.replace('#', '');
self.msgMeToThis(name);
};
}
var viewModel = new ViewModel();
ko.applyBindings(viewModel);
You can try to hide characters using html entities in hexa (ex: @ for #).
This is convenient solution, as a correct browser will translate it, and you can have a normal link.
The drawback is that a bot can translate it theorically, but it's a bit unusual.
I use this to protect my e-mail on my blog.
Another solution is to use javascript to assemble part of the address and to decode on-the-fly the address.
The drawback is that a javascript-disabled browser won't show your adress.
The most effective solution is to use an image, but it's a pain for the user to have to copy the address by hand.
Your solution is pretty good, as you only add a drawback (writing manually the #) only for user that have javascript disabled.
You can also be more secure with :
onclick="this.href='mailto:' + 'admin' + '#' + 'domain.com'"
One of my favorite methods is to obfuscate the email address using php, a classic example is to convert the characters to HEX values like so:
function myobfiscate($emailaddress){
$email= $emailaddress;
$length = strlen($email);
for ($i = 0; $i < $length; $i++){
$obfuscatedEmail .= "&#" . ord($email[$i]).";";
}
echo $obfuscatedEmail;
}
And then in my markup I'll simply call it as follows:
<a href="mailto:<?php echo myobfiscate('someone#somewhere.com'); ?>"
title="Email me!"><?php echo myobfiscate('someone#somewhere.com');?> </a>
Then examine your source, you'll be pleasantly surprised!
I wouldn't bother -- it is fighting the SPAM war at the wrong level. Particularly for company web sites I think it makes things look very unprofessional if you have anything other than the straight text on the page with a mailto hyperlink.
There is so much spam flying around that you need good filtering anyway, and any bot is going end up understanding all the common tricks anyway.
HTML:
<a href="#" class="--mailto--john--domain--com-- other classes goes here" />
JavaScript, using jQuery:
// match all a-elements with "--mailto--" somehere in the class property
$("a[class*='--mailto--']").each(function ()
{
/*
for each of those elements use a regular expression to pull
out the data you need to construct a valid e-mail adress
*/
var validEmailAdress = this.className.match();
$(this).click(function ()
{
window.location = validEmailAdress;
});
});
Spambots won't interpret this, because it is a lesser-known method :)
First, define the css:
email:before {
content: "admin";
}
email:after {
content: "#example.com";
}
Now, wherever you want to display your email, simply insert the following HTML:
<div id="email"></div>
And tada!
I use a very simple combination of CSS and jQuery which displays the email address correctly to the user and also works when the anchor is clicked or hovered:
HTML:
moc.elpmaxe#em
CSS:
#lnkMail {
unicode-bidi: bidi-override;
direction: rtl;
}
jQuery:
$('#lnkMail').hover(function(){
// here you can use whatever replace you want
var newHref = $(this).attr('href').replace('spam', 'com');
$(this).attr('href', newHref);
});
Here is a working example.
I don't bother. You'll only annoy sophisticated users and confuse unsophisticated users. As others have said, Gmail provides very effective spam filters for a personal/small business domain, and corporate filters are generally also very good.
The best method hiding email addresses is only good until bot programmer discover this "encoding" and implement a decryption algorithm.
The JavaScript option won't work long, because there are a lot of crawler interpreting JavaScript.
There's no answer, imho.
!- Adding this for reference, don't know how outdated the information might be, but it tells about a few simple solutions that don't require the use of any scripting
After searching for this myself i came across this page but also these pages:
http://nadeausoftware.com/articles/2007/05/stop_spammer_email_harvesters_obfuscating_email_addresses
try reversing the emailadress
Example plain HTML:
<bdo dir="rtl">moc.elpmaxe#nosrep</bdo>
Result : person#example.com
The same effect using CSS
CSS:
.reverse { unicode-bidi:bidi-override; direction:rtl; }
HTML:
<span class="reverse">moc.elpmaxe#nosrep</span>
Result : person#example.com
Combining this with any of earlier mentioned methods may even make it more effective
One easy solution is to use HTML entities instead of actual characters.
For example, the "me#example.com" will be converted into :
email me
A response of mine on a similar question:
I use a very simple combination of CSS and jQuery which displays the
email address correctly to the user and also works when the anchor is
clicked:
HTML:
moc.elpmaxe#em
CSS:
#lnkMail {
unicode-bidi: bidi-override;
direction: rtl;
}
jQuery:
$('#lnkMail').hover(function(){
// here you can use whatever replace you want
var newHref = $(this).attr('href').replace('spam', 'com');
$(this).attr('href', newHref);
});
Here is a working example.
Here is my working version:
Create somewhere a container with a fallback text:
<div id="knock_knock">Activate JavaScript, please.</div>
And add at the bottom of the DOM (w.r.t. the rendering) the following snippet:
<script>
(function(d,id,lhs,rhs){
d.getElementById(id).innerHTML = "<a rel=\"nofollow\" href=\"mailto"+":"+lhs+"#"+rhs+"\">"+"Mail"+"<\/a>";
})(window.document, "knock_knock", "your.name", "example.com");
</script>
It adds the generated hyperlink to the specified container:
<div id="knock_knock"><a rel="nofollow" href="your.name#example.com">Mail</a></div>
In addition here is a minified version:
<script>(function(d,i,l,r){d.getElementById(i).innerHTML="<a rel=\"nofollow\" href=\"mailto"+":"+l+"#"+r+"\">"+"Mail"+"<\/a>";})(window.document,"knock_knock","your.name","example.com");</script>
A neat trick is to have a div with the word Contact and reveal the email address only when the user moves the mouse over it. E-mail can be Base64-encoded for extra protection.
Here's how:
<div id="contacts">Contacts</div>
<script>
document.querySelector("#contacts").addEventListener("mouseover", (event) => {
// Base64-encode your email and provide it as argument to atob()
event.target.textContent = atob('aW5mb0BjbGV2ZXJpbmcuZWU=')
});
</script>
The only safest way is of course not to put the email address onto web page in the first place.
Use a contact form instead. Put all of your email addresses into a database and create an HTML form (subject, body, from ...) that submits the contents of the email that the user fills out in the form (along with an id or name that is used to lookup that person's email address in your database) to a server side script that then sends an email to the specified person. At no time is the email address exposed. You will probably want to implement some form of CAPTCHA to deter spambots as well.
There are probably bots that recognize the [at] and other disguises as # symbol. So this is not a really effective method.
Sure you could use some encodings like URL encode or HTML character references (or both):
// PHP example
// encodes every character using URL encoding (%hh)
function foo($str) {
$retVal = '';
$length = strlen($str);
for ($i=0; $i<$length; $i++) $retVal.=sprintf('%%%X', ord($str[$i]));
return $retVal;
}
// encodes every character into HTML character references (&#xhh;)
function bar($str) {
$retVal = '';
$length = strlen($str);
for ($i=0; $i<$length; $i++) $retVal.=sprintf('&#x%X;', ord($str[$i]));
return $retVal;
}
$email = 'user#example.com';
echo 'mail me';
// output
// mail me
But as it is legal to use them, every browser/e-mail client should handle these encodings too.
One possibility would be to use isTrusted property (Javascript).
The isTrusted read-only property of the Event interface is a Boolean
that is true when the event was generated by a user action, and false
when the event was created or modified by a script or dispatched via
EventTarget.dispatchEvent().
eg in your case:
getEmail() {
if (event.isTrusted) {
/* The event is trusted */
return 'your-email#domain.com';
} else {
/* The event is not trusted */
return 'chuck#norris.com';
}
}
⚠ IE isn't compatible !
Read more from doc: https://developer.mozilla.org/en-US/docs/Web/API/Event/isTrusted
I make mine whateverDOC#whatever.com and then next to it I write "Remove the capital letters"
Another, possibly unique, technique might be to use multiple images and a few plain-text letters to display the address. That might confuse the bots.