My user is filling out a small form (just the email address) and I send this data to the server via javascript. I send the form, then clear the data from the fields.
Is it bad practice to simply give the user a js alert like alert('Your email has been added') as opposed to adding markup to display the message? I don't see it often today, so I'm wondering if it reflects some perception that using alerts isn't good. It makes the code much easier though, and I wonder why not!
And a side question, is it possible to just style this alert so it doesn't look so bad?
alert interrupts the user in whatever he was doing. That's not good and should only be done if it is absolutely necessary. An alert is not necessary, because the user has only one way to continue anyway.
It's not a very pleasant user experience when popup alerts keep appearing. Annoying as they interrupt what you are doing and you have to click on a button to carry on what you are doing. Excessive use makes it very unlikely that they will ever be read, causing big problems when something actually important comes up or the user has to make a choice.
Having more sophisticated feedback in the interface creates a much better experience.
Since you tagged this with jquery
$('#my-form').prepend('<p class="notice">Your email has been added</p>');
Was that really so hard?
If the main purpose of your page is to collect the email address I think it is perfectly valid to use an alert box.
I think the main reason you don't see this practise any longer, is that you have limited possibility to style the alert box.
I.e. it is not very Web 2.0
"And a side question, is it possible to just style this alert so it doesn't look so bad?"
Nope. And you can't change the title, design or anything like that, it's purely browser dependant!
I for one find it annoying when alerts pop up left right and centre, they're modal so you HAVE to click on them and while they were used a lot for that back in the day, these days it's generally much more accepted to write something into the web page. This has a number of advantages over an alert dialog:
You can skin it to suit your needs entirely
It doesn't annoy the user as much
Sometimes browsers these days can prevent sites from displaying alert dialogs at all (because they're so annoying)
An alert dialog disappears as soon as you click OK, you have to remember what it was moaning about or what it said. If it's built into the page then this information remains there for you to see.
If you genuinely need a modal-like dialog box these days (and for this case I'd say you didn't) it's far more common to use a JS library to emulate one. That way you can get the exact behaviour you want, it can look in keeping with the web page and can't be turned off by the browser.
alert() is largely seen as a non-graceful solution in terms of UI design these days. With that in mind, it really comes down to the environment - if it's a public facing consumer website, I avoid using alert() whenever possible as it disrupts the user's flow. If it's a backend-style corporate website, screw it, an alert can work fine there (but still use your judgement, lightweight markup never hurt anyone).
They're annoying, break the flow and personally I think they're only appropriate for 'alerting' users to something. Something like a message to inform you that you've been registered which is more 'confirmation. and the expectation in these Web 2.0 days is that such things appear in a more permanent form on the main webpage/ GUI.
In my opinion it's quite obtrusive as it blurs the difference between harmless web error messages (for example, you forgot to enter your password!) and more serious application errors.
Also if you don't handle them properly, you can't get 3-4 consecutive errors which is extremely annoying.
It's easy and quick to implement however, gets the user attention, and guarantees they won't be able to do anything until they have seen and pressed ok on the error message.
As for styling, you can't. But take a look at jGrowl, it has a really nice way of doing error messages.
Related
Not really a coding question, more theoretical and code is not needed as I know how to do it, but I'm not sure where else to ask this.
I have an idea for preventing spam bots from seeing that I have a form, but I cannot test this in local code. Can I just make the form completely javascript generated, and then write it to the inner html of a tag after a one second timeout? Seems too easy so there must be some reason why this wouldn't work. I can't find where anybody tried this and tested it for a while so I don't know if it will work or not.
So based on what anybody knows about how bots work, can they still see that I have a form, especially if the js is obfuscated? I would think that the bot would never wait around to receive this or detect the change in the html, but would it find the form in obfuscated js?
Google's search spider claims that it can run some/most JavaScript when it evaluates a page, so I think it is reasonable to expect that at least some spam bots can do this now, and more so in the future.
Additionally, some spam bots are actually real people working for a pittance, using real browsers, so overall this will not work in the long term.
I would like to know if there is a way to prevent an html page with jQuery or javascript to be modified by the user to change its behavior.
A user can modify it using tools such as FireBug or the Google Chrome developer bar to hide or show divs, add event listeners to page elements and so on.
I've seen some web pages showing a blocking div when the page is loaded and a pop-up telling to answer some question. If you answer it, the div hides and you can see the page normally.
But if you try to hide the blocking div using FireBug, the page reloads and there is no way to see the page correctly if you don't ansewer the question asked in the pop-up.
I want to know how could I prevent user from doing such things.
Thanks a lot.
It is not possible (which is a very good thing).
To defeat the method described in the question:
You can use the keyboard shortcuts to the console/tools (Ctrl+Shift+I in Chrome)
You can use the resource/net panel to see the source
You can see it at any other level, e.g. Fiddler
You can use a bookmarklet for easier access
No, you can't prevent people seeing or modifying your source/script if they want to...the ones you most want to prevent are the most able to circumvent any deterrent (and that's all anything you do is, a deterrent, not a stop) you put in place.
The only way to do it (in my opinion) is not have the page content load until the user does your desired action. After he answers the question (or whatever) you send an AJAX request for the content (of course, as thejh said, you should also validate the answer on the server, preferably in the same request). So you load page header, banners and anything not critical, but the actual content (say an article on a blog) should not be loaded until the user does your action.
Everything that a user's browser receives belongs to the user, so you can't enforce anything on that.
For sure you can't prevent anybody from doing what he wants to, but you can make changes more difficult.
Take a look at the DOMEvents, especially the Mutation-Events.
Those give you the ability to see when something has changes(attributes, removed/inserted nodes, data in textnodes ...). For example you could build a function that watches some special attributes you would'nt have to get changed and reload the page, if this happens.
As others have already said, it isn't possible to control what the end user does with data you've sent them.
It may be possible to detect the console object that Firebug and others use, but what can your site do with that information once you've got it? You can't disable firebug or prevent it from being used, or even know whether it has been used.
The bottom line is that once the web page and javscript code have been sent to the browser, it is out of your control.
The closest you can get to what you want is to move some of your code out of Javascript and to the server, where it will be untouchable by the user. However you'll still have to have some client-side code, which will still be at the mercy of malicious users.
The other alternative is to move to Flash or something similar, where the end user doesn't have direct access to the code or the object model. This has it's own downsides though, and you'd be bucking the trend, which is to move away from Flash toward HTML5 and Javascript.
It's impossible. When you send code to the client, the client can look at it and modify it. Only code that runs on your server is protected aganist that.
I don't think it's possible to do that unless you can make sure (or force) users to use browsers that don't have developer tool.
Use ajax to get remote information don't send the user all the information such as answers to polls etc get the answer after he picked a choice from the server using ajax for example. Client-side validation is never a good thing hell thats how I used to delete other stupid people's databases due to that unless people learn properly how things REALLY work they should get taught the hard way such as losing everything in a case of root access vulnerability.
I don't know why HTML has to be blocked it wasn't blocked since browsers came out he'll I could make my own browser with a socket and get HTML transfered right to some textbox and see it in my favorite notepad/editor etc..
As for javascript you can simply send javascript commands in browser address bar (how convenient of browsers in supporting hackers hehe but it's also used for inter-op communication with other technologies such as flash so it has a evil/good side to it as everything.)
If you didn't know you can just do
javascript: alert('hi');
or if your javascript game or whatever has globally scoped variables you can modify em easily
javascript: score=9999;damage=99999;
etc etc like i said it's all good it weeds out the bad programmers and gets em fired or teaches em a lesson in the future.
I've seen many big sites still fall to a SIMPLE XSS attack (Cross-site scripting) which is just baffling how these programmers get a job, I'd do a better interview or some shit it's ridiculous
I'm trying to create a button on my webpage that, when clicked, embeds a particular div into an email and sends it out. I want the email's look and feel to be exactly like the webpage (minus the Javascript of course). That is, it should resemble the behavior of clicking file>share>email in Safari, except that I only want parts of the page and not the entire thing.
Is there any easy way to do this? Your help is very much appreciated.
Update:
So I ended up using AJAX to invoke a PHP script to do this, with the help of this library: http://pear.php.net/package/Mail_Mime
Still struggling with the CSS, but it looks pretty promising so far.
It sounds like you want to be able to have the browser talk to the user's email client (i.e., click on mailto:test#test.com and have this bit of HTML appear in the email client ready to be sent off). That won't happen with a regular browser and javascript, because the window doesn't know anything about what other programs are available or in use on the user's machine. You'll need to send the HTML to the server and have the server send the email. Also, I've been told that CSS styling for email is very difficult, so having the 'look and feel be exactly like the webpage' is going to be tougher than you probably think.
All that said, it is very doable. You just need to focus your effort on getting the HTML to the server and then deciding what library to use to send the email (depends on the language). That's only half the battle, though, as you'll need to work just as hard to style it and test it on a variety of email clients (I assume). I've never done CSS for email before, but I'm pretty sure that's what's generally involved.
The site I'm working on displays some proprietary 3rd party data that's quite valuable. As such they want to stop people copying and pasting their information. They understand that, of course, there's nothing we can do to stop users just writing down info or printing it off, but they want to make it as difficult as possible for their data to be taken. The other big concern is performance. The site sees a healthy amount of activity, so keeping it snappy is a big deal.
I was hoping to get a bit of feedback from you guys on the best way of accomplishing this
Some potential solutions that have been suggested:
Use a bit of javascript to stop users hitting ctrl / right clicking (irritating and won't stop more advanced users)
Use flex (very slow, but very safe since the data is binary)
Create or find some funky html to image converter and display the data as images
Your thoughts and opinions are very welcome.
Thanks in advance!
Charge the users for access to the information.
You can try all sorts of code workarounds, but you really aren't going to stop anyone who is determined. By charging, you limit access to people who really need the information and if they copy it, then at least you've been reimbursed. It also filters out a lot of the people who would use it maliciously. Also, put a legal notice on the information detailing how it can be used so that you can follow up copiers with legal action if necessary.
This really sounds like a serious problem with the origins of the question. If this is something that shouldn't be easy to copy, why is it visible at all?
If its really proprietary, why is it a good idea to post it on the web?
Seems that an internal webpage would be more appropriate.
It is a tricky situation, since this is the web...
You could use a very small bit of flash to display the sensitive data, which you'd have complete control over, and if it's small, shouldn't hurt your download times. This would probably be my preferred method.
Option #3 would stop people from copying and pasting, but it wouldn't stop them from downloading the image. I'm not sure if that matters to you.
Do you need to serve audiences that have javascript turned off? If not, you could use AJAX to pull the sensitive information in the first place, then use a script to stop them from copying that div or whatever.
You might want to check out Tynt Tracer. It doesn't prevent copying, but at least allows you to track where it's going...in part anyway.
You might look at the option 1, as a "bare minimum" way of doing it, but admittedly it isn't a great option, as simply disabling JS gets around it.
Your third idea would also work, but you can actually make it easier to save by going to the image and the way they are stored in temporary internet files.
Also, as a side note, to prevent printing you might want to specify a print only CSS that hides all content.
body {display:none;}
It isn't perfect, but again stops the casual user from printing.
Charging money for the content is a good answer, but I'm guessing you're already charging for the content.
#2 is clearly the most secure option, and the most flexible, allowing you to really punish yourself as much as possible as well (do things like implement over the wire encryption etc...) So it should come as no surprise it is also the most expensive to implement.
Given, someone can just decompile your code and inspect memory, but at that point, it is doubtful you are going to stop anyone.
Offer the information for download in password protected pdf, where the only thing that they can do is to view it, no printing, copy paste, etc. Although you can't stop a print screen. Primo PDF can do that for you and is free. http://www.primopdf.com/
They key here is the that effort it takes to bypass any solution you choose, is greater than the value of the information you are trying to protect from being copied.
At my company most inventory tracking is done via an ASP.NET web application. The application is poorly conceived, poorly designed, poorly implemented, and somewhat of a hassle for a user to work with. These are things that are my opinion though and management has its own thoughts on the matter.
Such luxuries as the browser's back button and bookmarking pages are already not an option because of heaps and heaps of ancient Ajax code and now one of my bosses has the idea that he would prefer for the URL bar and browser buttons not to appear at all.
At first I told him that it was impossible but after thinking about it I suppose it could work if you used Javascript to create a fullscreen pop-up and run the application in that.
I personally am against this idea though since I'm the one who would do the work my own subconscious motivations are suspect so I'd like to gather some opinions on running an application in such a manner.
In addition, has anyone had any experience with transferring a regular webapp to such a setup? I'd like to know how much work could be in store for me.
Next time, for the good of the world, keep these kinds of ideas to yourself. It sounds like your boss is not qualified to make such a call, so make the call for him.
If your boss believes the url bar and browser buttons are not suppose to be there, then convert it to a stand alone app. Don't try to cram it into a web platform if its not suppose to be one.
You know the issues, so fight for what you think is right. Don't implement anything you are not going to be proud of.
You may find Prism intresting
Full Screen, no bars, just WebApp
I'd be tempted to simply add a button that allows you to pop out the app, without removing the normal mode.
If necessary, sell it with some waffle about users getting confused or not being able to reopen it or something. Or even pretend its not possible to do it without it.
That goes some way towards user friendliness. Salve your conscience anyway