I have a link like the one in the title in a custom 404 error page, which allows the user to go to the previous page just like with the browser's go back button. I just wanna ask if this method of linking is safe or not. I guess it is safe, but I am not sure. Thanks in regards!
One use case I can say that will not be "safe" is if the user has JavaScript disabled. In that case, you would have to create the link dynamically with server-side code using the HTTP referer header field's value as your href value on the anchor element.
Another thing to consider is the never-ending back and forth loop users would get stuck in, if they came from a page with an HTTP redirect.
Edit:
As you said above, you can use $_SERVER['HTTP_REFERER'] but the documentation says
.. This is set by the user agent. Not all user agents will set this,
and some provide the ability to modify HTTP_REFERER as a feature. In
short, it cannot really be trusted.
In reality, most browsers do set it correctly though, and seeing how this is not mission critical I think it's safe if you use it. You could also account for browsers that don't set it as follows:
if(isset($_SERVER['HTTP_REFERER']))
{
// Show a Back button link, if the referrer is available
echo "« Back";
}
else
{
// If not, show a link to your homepage instead
echo "Home";
}
Related
Is there a way to hide the url in the address bar with Grails application. Now users of the web application can see and change the request parameter values from the address bar and they see the record id in the show page.
Is there a way in Javascript or Groovy (URL Mapping) or Grails (.gsp) or HTML or Tomcat (server.xml or conf.xml or in web.xml inside application in the webapps)
ex(http://www.example.com/hide/show /) i want to avoid this url and always see (http://www.example.com) or (http://www.example.com/hide/show) without the record id
Is there a way to prevent this?
No, most browsers doesn't let you hide the address field, even if you open a new window using window.open. This is a security feature, so that one site can't easily pretend to be another.
Your application should have security checks so that one user can't access data that only another user should see. Just hiding the URL would not be safe anyway, you can easily get around that using tools built into the browser, or readily available addons.
It's part of the restful URL pattern implemented by grails.
Your best bet to hide the URL would be using an iframe within the page you want the user to see in their address bar.
Not quite sure what you mean, but I would change the default root URL mapping in UrlMappings.groovy so it looks a bit like this:
static mappings = {
"/$controller/$action?/$id?"{
constraints {
// apply constraints here
}
}
//Change it here!!!!
"/"(controller: 'controllerName', action: 'actionName')
Where 'actionName' and 'controllerName' are what you want them to be - 'hide', 'show' in your example?
Than pass all parameters via a post instead of a get, just change the <g:form> method.
You will still obviously need to implement any security checking required in the controller as stated by other posters.
Thanks,
Jim.
You can probably handle this using a variation of Post/Redirect/Get:
http://en.wikipedia.org/wiki/Post/Redirect/Get
At our Grails site we have a lot of search fields. When a user clicked a pagination link all those search fields ended up in the URL which created ugly URL:s with a higher risk that users bookmarked those addresses which could mean future problems.
We solved this by saving not only all POST but also GET with parameters into the session, redirect to GET without parameters and append those again in the controller. This not only creates nice URL:s but also a memory so that if a user goes back to an earlier menu, then selected details within that menu are redisplayed.
For your specific request to hide the id in "show/42" you can probably handle that likewise or possibly configure Grails to use "show?id=42" instead, but we don't have that requirement so I haven't looked further into that issue. Good luck!
Forgot to mention: this won't add much to security since links will still contain ids, it will only clean up the address bar.
Here's some sample code that should work. If show?id=42 is called, it saves id=42 in the session, then redirects to just show and id=42 is added to params before further processing. It does what you want, but as commented it might not always be a wise thing to do.
def show = {
if (request.method == 'GET' && !request.queryString) {
if (session[controllerName]) {
params.putAll(session[controllerName])
// Add the typical code for show here...
}
} else {
session[controllerName] = extractParams(params)
redirect(action: 'show')
return
}
Still now I knew Its not Possible to change the contents of location bar without changing the page (and Yes I am not talking about #). I've recently noticed github.com. How they are doing that on their site ? they can easily get an event when user clicks on Browser's back or next button. dojo.back also have this feature. But how to change the addressbar with javascript without leaving the page ?
There are two ways:
HTML5's pushState() function. Facebook and Github use this, for example. It allows you to modify the complete URL and fires event handlers when the history state changes. Mozilla has a good overview.
The old variant is to use the hash part of the URL (this is what Twitter does). This means that you change window.location.hash, monitor it for changes and, based on the value of that hash, load the appropriate content. However, this means that when the user requests, say, http://twitter.com/#!/27c3/status/18331752900591616, only the part before the hash sign is requested form the webserver, everything after the hash is only the client's business. This means that the server can not yet decide what content to hand to the client.
try dojo.hash
What you're referring to on GitHub is the # (hash). When you right click on a line number, it adds the number to your hash.
window.location.hash = 'HELLO';
Put that in a page to try it out. It's not possible to change window.location without the page reloading. The back button stuff is a little trickier, but Dojo is your best bet for that. jQuery doesn't provide this. Dojo has pretty clean code though, so you should be able to reverse engineer their functions (if you chose to include that functionality into your own library).
You'll also notice Google is doing the same with: http://code.google.com/p/digitalxero/source/browse/#svn%2Ftrunk%2Flocale%2Fde
If you click on folders (left), it changes the hash, and provides different content.
I have a question, is it possible to get the url from the history.go(-2)?
Assuming i don't know that url.
edit
I need the url, because I want to check where the visitor was redirected from. there are two cases: 1 facebook, 2 directly on the website. the second step is an automatic user check. the third step is miscoded, but if I go back to step 1. I can bypass the error. with everything working fine. the problem is that I don't know where to redirect (being two forwarders).
It is not, by design, for privacy reasons.
You can in some special circumstances get the previous URL with history.previous (and likewise for .current and .next) but you can't look back arbitrarily and see where I (the visitor) went two or three or ten pages ago. From a website, reliably getting even the most recent page URL (which is sometimes available as the "referer") is never guaranteed.
Thinking about it from your visitor's perspective, this is good. Just because I'm visiting your site now doesn't mean I want you to know about every other page I've ever visited in the same browser window.
No, not in general.
If the URL is on the same hostname as the current page you sort of could, by opening a pop-up window, navigating back 2, then using script in the pop-up to read the opener.location, navigate forward 2, and pass the URL to script in the opener. But it would be an enormous pain and pretty unreliable.
If the URL isn't on the same hostname, you can't at all, for privacy reasons.
I'm not sure if this is possible with your set up, but you could add a GET veriable (ie. page.ext?ref=1) and then store that in a session and output it on whatever page you need. Then, on your facebook page, you could add ?ref=1 to the link. This would allow you to add other site references in the future as well.
It probably isn't possible as history.go() does a URL redirection.
You can get the previous/next URL by doing history.previous/history.next property respectively. This returns you an absolute URL. For current URL, use history.current.
More info on history object.
DevGuru.com
Exforsys.com
If JavaScript is disabled what's a way of linking to the previous document in the session history?
Can PHP be used to simply link to the REFERRER or is there a better alternative?
Edit: Further to this, can previous post variables be retained?
You're really mixing the idea of previous document in client session history vs. server session history.
Since Javascript is client-side, executing a history.back() renders the control to the browser, which then decides which page was last in the history (keeping in mind that the last page may not be a page within your domain). When you're using server-side PHP, the HTTP header referrer is whatever the browser supplied to you. If your server-side URI wasn't called as a result of an explicit click on a link, form GET/POST, etc. , your script probably won't get a referrer header value.
If you only want to capture the referrer within your site's domain, you can start maintaining a breadcrumb trail server-side (in the user's session). eg: $_SESSION['breadcrumbs'] = array( 'page1', 'page2', ... )
POST variables can be persisted in the SESSION too though I've never seen a good reason to do so. If you're trying to return an error message for a form and expect to get back the POST, you shouldn't be saving the state of the original POST.
I've never learnt JavaScript, but I imagine this is quite a simple problem. Just wanted to know which method is most advised these days.
// use this to avoid redirects when a user clicks "back" in their browser
window.location.replace('http://somewhereelse.com');
// use this to redirect, a back button call will trigger the redirection again
window.location.href = "http://somewhereelse.com";
// given for completeness, essentially an alias to window.location.href
window.location = "http://somewhereelse.com";
edit: looks like the user who posted the better answer has left SO, i've consolidated his answers here.
Most advised? To not do it. HTTP is far better suited to the job than JavaScript is (search engines follow them, you can state if it is permanent or not, they are faster, etc).
Failing that…
If you want an immediate redirect:
window.location.replace('http://example.com/');
This will replace the current URI with the new URI in the browser history, so the back button won't land the user on a page that immediately throws them forward again.
If you don't really want to redirect, but want to send the user somewhere in response to an event:
window.location.href = 'http://example.com/';
Remember to have a non-JavaScript fallback. A link is usually the best option, but it does depend on context.
Time delayed redirects are an even worse idea. The only reason to use them is if you want to display a message to the user - and users read things at different speeds (and have them sitting in another tab while they do something else). If the message is important enough to show, then it should be important enough to leave on screen until the user has read it and clicked a link to the next page.
One important thing to remember when redirecting a page using JavaScript is, always provide a non-JavaScript redirect as well! A link would do, or better a <META> tag, for example: <meta http-equiv="refresh" content="2;url=http://example.com">
These days, I think the most advised method is not to do javascript (or meta) redirects. Do you really need it ? Could you use a redirect HTTP header instead ?
The W3C's Web Content Accessibility Guidelines (7.4) also discourage the creation of auto-refreshing pages, since most web browsers do not allow the user to disable or control the refresh rate