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.
Related
Hi I'm new to dynamic web dev. I've searched this site but couldn't find anything similar.
I want to implement a password checker, for robustness and length etc. Fairly conventional. The thing is, I have 2 options: 1. embed javascript inside an HTML. 2. embed javascript inside a jsp file.
With a little preliminary research it seems that most people recommend the former, that is to go with HTML. I wanna know why? I could be completely wrong, in that case I also wanna know why?
The "how" isn't all that important, but "why".
Edit: I know this question is full of flaws (for example JSP and HTML aren't mutually exclusive) but please indulge me a little bit and tell me which scheme is more appropriate, if I want to get things done front end, in a user's browser.
Edit#2 : Sorry I did not provide any bg information: I am working on a larger project and password checker is just a part of it, the project itself is a dynamic web project relies predominantly on java, serverlet.
As you state you are new to dynamic web dev. JSP is a server side programming language Just like PHP and others. If you want to confirm password, you can use ajax to check for a match from your database and if match was found create a session and redirect your user to the logged in page. If i misunderstood your question, please try to be clear enough.
Depends on your use-case. In some cases, just the front-end is enough. In many, I would say both is better.
By putting it in the front-end/client-side (the "HTML"), you create a more user-friendly approach, since you can rapidly and continuously evaluate the users' input and give them feedback.
If the application doesn't need to be particularly robust from a security perspective, this can be plenty.
The downside of HTML only validation of any user input is that it can easily be bypassed. As a programmer, I could figure out what its doing and easily bypass any and all client-side protects. Users can also wholesale just disable JavaScript, so if your site works without JavaScript in general, they won't get any validation. This is why "security" on the client side is never a thing. Never trust the client.
Implementing it only on the back-end/server-side ("JSP"), you can lock down the security since the end-user can't bypass any of your validation. It must match the rules you set forth.
The downside to server-side is that you must send the data to the server to be analyzed, then wait for a response. While this may be fast, its still much slower than client-side.
By doing it in both, you get the best of both worlds. You get the rapid feedback for the end-user without having to send any data to the server, and you get the full protections of making sure it is properly validated on the server-side.
The downside to this of course is you have to double-up on your code, so its more effort. That's why you want to weight the pros and cons in your particular case, as there isn't a single "best" answer.
If the HTML is enough for you - why should you use .jsp?
You need .jsp for creating dynamic content and it's gonna be compiled as Servlet - do you actually need Servlet in this case?
If security is not a big concern then HTML + javascript should be fine. It will be responsive amd lead to better user experience.
If this is an external facing application on the web then as mentioned in some of the other answers go with Jsp approach.
I am a newbie game maker that making some web games with the language of JS, HTML and CSS. But the problem is i can't prevent the right click inspect hacking thing, so a people hacked my games by using this method.
My question is, how can i prevent this method to not to being hacked...
Here is my game http://ozansiar.com/mario/oyunok.php
Here is the score page http://ozansiar.com/mario/skorekran.php
as you can see it can be hacked...
Language is Turkish, sorry for not doing this in English, but i will.
Second question is, how can i improve my game developing? I heard that phaser is a good engine, so i'm doing a research for reach to some tutorials. But also, i need some good advices from you...
Sorry for my newbie questions, but i do need some good advices to improve my web development and also game development skills... Thanks so much!
Note : Games are made by what i learned from stackoverflow community... So also thank you very much for this.
Client-side code (HTML, CSS, JavaScript) is called "client-side" because it is downloaded to the client and executed there. There is absolutely nothing you can do to protect this code from users seeing it and modifying their local copy of it. Even storing your JavaScript in an external file and linking to it does not solve the issue. The same is true with obfuscation.
All protected code should exist on a secure server and execute there in a "server-side" architecture, such as .aspx, .PHP, .jsp, etc.
So I just ran through the game and "hacked" it. The problem you have is that you use forms and hidden inputs to send the game results to the server, first when the user finishes the game you submit the time it took them, then on the second page you send their final score in a hidden input. Both of these can be easily modified by the user before they're submitted.
What you could do is create a checksum of the hidden values that you don't want the player to modify. After they're posted to the server, use the values to re-calculate the checksum in PHP, and if it doesn't match the checksum submitted by the browser, don't accept it.
This won't stop people from hacking your game, but it will make it more difficult. If they absolutely want to fake their score, they can look up the javascript function you use to generate the checksum on the client side and use that to generate a new one with the values they want, so it's not 100% secure.
As for the final score, I'd suggest you use a session for that. Your skor.php file generates a form with the final score in a hidden input. Why? Just dump it in a session property, and read that back in skorislendi.php. That way, the user won't be able to edit it.
You can't prevent the client, i.e. the player, from hacking client side materials, i.e. client-side scripts, HTML and etc... Any legitimate actions that your scripts perform on the client side can be faked. At best, you can mitigate such hacks by obfuscating your JS code and post data. This makes it harder to hack but doesn't save you.
In the end, ask yourself this one question. Is security essential to my game? If it is, then worry about it. Otherwise, build what you can and from an agile point of view, add features, such as security, when NECESSARY.
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 would like to make a simple web calculator to allow some field technicians to enter numerical data into it and calculate a result. The problem is that the page will be hosted publicly, though our calculations are something we'd like hidden from outside interests. Is there a way to hide the formula or call an outside script so we don't expose our methods to people who may want to inspect the .html file?
I have experience writing basic HTML but am far from a web developer. Please give links or detailed instructions if possible. Thanks in advance.
If the calculations will be done in the browser, then the code to do the calculations must be sent to the browser. If the browser can figure it out, so can a person.
If you are really serious about hiding your algorithm, you should probably create a service that runs on a server that you control. The web page would collect the inputs, send them to the server and respond with the outputs from the calculation.
EDIT:
Welcome to StackOverflow!
If you want your calculation algorithms executed on the client, you're out of luck. Anything you send to the browser must be considered "open". The only method of hiding anything is obfuscation, and that is usually easily undone.
If hiding your algorithms is more important you will need to have a server that performs the operations and exposes an API for the client to access. (EG: Client says "hey server, calculate X for me" the server performs the algorithm with X and sends back the answer)
There's no way to do this with Javascript inside of a html file. You can minify or obfuscate which can help a bit. This can make the Javascript harder to read or understand but it's relying on security through obscurity, in other words, if someone is determined enough they can figure out what's going on.
The best way to solve this is to set up a server that does the calculations. A client webpage can send a request to the server and return the results, while preventing people from seeing how it's done. This is how Google keeps it's search function private despite returning the results.
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.