I have a URL with a query string attached to it. After the page loads, I am removing the query param using
history.replaceState("","",location.href.substring(0,location.href.indexOf("?")))
But when user hit refresh button its displaying error screen from my application since expected query param was not there in URL. I can use post action there but I would like to avoid query params with page refresh working fine. Is there any solution for this ?
If you're using a query parameter and then removing it, then the user hit's refresh and there is an error saying it's expecting a query parameter, then your code (and logic) is lacking.
My suggestion, if you want to avoid query parameter after the page initially loaded, is to save the parameter in a cookie or even a session if there is code-behind. Then if the user refreshes without the query parameter, check if the cookie exists, if the cookie exists, show them the page normally, if not, instruct them that they did not visit the URL through the correct channels.
However, like I mentioned, I think your logic here is flawed, because if the user wants to share your URL to the outside world, and you removed the key piece of information that makes the page load successfully, then you will have a lot of confused people on your hands
edit
You might want to investigate SEO friendly URL's to pass your query in to, so instead of: yoururl.com/?firstname=joe you can do yoururl.com/firstname/joe
Related
I am currently working on a task where for example an user visits www.site.com satisfying a particular condition I am supposed to make some visual transformations in the page. But this should only happen for the first time the user is shown the page. Subsequently if the user ignores the call to action and browses the site everything is normal.
To make sure that for a given session this transformation only happens once I am using document.referrer to check if it is
1. an "" string which means user might have entered the www.site.com address directly
!document.referrer.match(/www.site.com/gi); - to make sure that the user is not referred from the internal pages back again to the home page.
This works in most cases except when user gets into the check funnel the url changes to a secure one https:// and when he is referred back to site.com home page the document.referrer returns an empty string which confuses my logic a the user is entering the address in the URL
Is there any other reliable way to solve this problem. Any help is much appreciated and thank you for taking time to read my problem
function transformation(){
// transformation code
}
if(document.cookie.match(/someCookieName/) && document.location.href.match(/transformationPageURL/)){
// call the transformation
transformation();
// set session cookie
document.cookie="someCookieName=true;";
}else{
// not the url to perform transformation or the cookie is already set which means its the same session.
// but still if the user again enters the same home page url the transformation //would not appear due to the cookie being set. But the changes of normal user //visiting the website and again entering the url of home page might be less
}
I have a drop-down selection of available languages. Currently, clicking on a language is mapped to a method in controller which updates the Play Session (which is a cookie under the hood) with the selected language and returns index page.
View:
English
Controller:
def setLanguage(language: String): Action[AnyContent] = Action { implicit request =>
val updatedSession = request.session + (("lang", language))
Redirect(routes.Application.index()).withSession(updatedSession)
}
As you can see, I redirect to index page and it's working fine. However, as the language selection is available at all times on my page, it may be clicked from /resource1, /resource2, /resource3 etc. and I would like to refresh that particular view instead of being returned to home page. I cannot simply get request.uri in the controller and refresh whatever it's pointing to because setLanguage() is mapped to its own route, so my request URI is always /language?lang=whatever.
So, how do I know that prior to invoking GET on /language, client was on, say, /items so I can reload items page instead of returning him to home page? Should I send a GET request with resource as a parameter (e.g. ?lang=en&location=items) to know which page to render? Should I make an ajax request and call window.location.reload() on success? Do I even need to go to server or can I simply update the PLAY_SESSION cookie manually from the client?
I'm using Play 2.3.7.
No you cannot update the PLAY_SESSION cookie from the client side, since it is signed by play with the application secret.
So I think the easiest solution would be, as suggested, to send the current resource as parameter and trigger a redirect.
There is an HTTP header called Referer that contains the url from which the request was made. As far as I know it's supported and used by all modern browsers when you navigate from a page to another.
You can simply redirect to that Referer url.
Another solution is to track in a session or a cookie all pages that are accessed by an user, by using some kind of interceptor in Global.scala or a custom Action builder that you use everywhere. Then in case of language change you can simply redirect to the last page that was accessed by the user.
The setup is basically having Page A with anchor links as such
<a href="/index.php/iframe-wrapper?http://www.[desired link].com">
upon click, the URL is written as such in the users browser
http://www.[site].com/index.php/iframe-wrapper?http://www.[desired link].com
an iframe calls what comes after the querystring through javascript and displays it in the frame through
var query = window.location.search.slice(1);
basically being able to have URLs on Page A display in an iframe on Page B
im stumped on how to remove the querystring from the end result (maybe through htaccess?) (as it is modifiable on any user browser leading to all sorts of vulnerabilities)
if anyone would be able to help me out with htaccess or some other similar method, i will be deeply grateful
I'm not aware of any way that .htaccess could help decrease the chance of vulnerabilities. You're still accepting a query string and using that as the iframe source, which means anyone can still just submit any URL in the query string regardless.
A more secure way to handle it might be to create a database table containing all of the potential URLs. You could enter them manually, or if they change frequently you could have a secure form where authenticated users (or admins) can administer them.
Then in the query string of the link you can simply pass the id of the table row which contains the URL you want to use, and retrieve the appropriate URL for that ID server-side using PHP.
In this way, the iframe can only ever display one of the URLs that are stored in the database. Someone could still enter whatever they want in the query string, but it won't matter because if it's not the ID of a valid URL you can display an error message (or a default URL or whatever other fallback behavior you want).
I know that I can find out the referrer using:
document.referrer;
However, I have a one page website, and a redirection set to send all other pages in that website to the home page. I would like to have a way of capturing the link that originated the redirection. In this case, document.referrer is always empty.
So I guess, I need to know:
How do I set a referrer parameter before the redirection?
How do I capture that parameter with JavaScript in the home page?
You could pass it along in a URL parameter. For example, Google does something similar when you click a search result; the browser actually goes to google.com/url?url=https%3A%2F%2Fthe-site-you-want.com.
So you could redirect your users to 'http://your-site.com/?referrer='+ encodeURIComponent(document.referrer), and then once it hits the homepage, you can extract that value and run decodeURIComponent.
encodeURIComponent is a method that makes a value safe to put in a URL. decodeURIComponent is the reverse process.
Alternatively, you could put it in a hash rather than the querystring, like 'http://your-site.com/#'+ encodeURIComponent(document.referrer). Several client-side routers use this. Although that may break the back button unless you spend more time learning about pushState. When Twitter first used twitter.com/#!/foo-bar as a URL scheme, it broke many things. But it may be useful to you.
Could anyone clarify how the GA actions _gaq.push(['_link', <href>]); and _gaq.push(['_linkByPost', <form>]); work?
I'm not interested on how to use them as presented in the documentation. I understand those scenarios. I want to know more about what they do when called.
Edit:
I suspect how this works but I need some confirmation from someone that fiddled with this longer than me. I want to know what the process is in each of the cases in small steps. I know that it changes the sent data in order to overwrite to cookie on the target site, but I need to know exactly the actions that happen (in terms of JavaScript on the sending page) after you do the push.
I would also like to know if I could use _gaq.push(['_link', <href>]); from anywhere in my code to change the page.
Thank you,
Alin
We will assume _gaq.push(['_setAllowLinker', true]); used on any needed page.
What _gaq.push(['_link', <href>]); does:
Appends the __utm<x> cookies to <href>. You need to return false in the onclick of the anchor so that the original link does not follow through.
Changes the browser location to the newly formed URL.
What _gaq.push(['_linkByPost', <form>]); does:
Changes the action attribute of <form> so that it includes the __utm<x> cookies.
What happens on the target page:
The GA script on the target page checks the received parameters and if the __utm<x>s are sent it overwrites its own cookies with these. This results in identifying the user as being the same on that left your original page.
As a bonus _gaq.push(['_link', <href>]); can be used in (almost) any situation window.open(<href>); can be used.
They pass the cookie information from one domain to another; in the instance, it does this by appending a query string on the next page; with _linkByPost, it sends the cookie information as GET parameters on the form action along with your POST data.
If _setAllowLinker is set to true on the target page, the cookie information sent will overwrite the default Google Analytics cookies on the target page, and will allow for linked, consistent session information between the two, as the cookies will ensure that consistent data is shared.
EDIT:
No, you can't call it from anywhere in your page, unless you bind it to an onclick of where you'd like it called.