My web app runs under Tomcat, it uses AJAX requests very intensively, and during the development process I have to redeploy the web app intensively too. After the redeployment I usually simply refresh the page knowing that the user session is dropped, but I always get to the scenario described below:
Go to some page, a really big page with many JS-scripts included, that actually makes those intensive AJAX requests.
Stop Tomcat or redeploy the web app.
Refresh the page.
Enter the credentials in the sign-in form to authenticate.
Suddenly get the last AJAX request response in the browser window and the AJAX request URL in the URL bar.
Wow... It looks strange for me that AJAX request URLs appear in the URL bar along with their response in the web page display area. This actually happens to Firefox and Chrome (haven't tested it in other browsers). Unfortunately, I cannot reproduce the same behavior in a simple page written from scratch. Frankly speaking, I don't really understand what happens to such requests and why do browsers "think" if AJAX requests/responses are entered in URL bar by user...
Your possible explanations or hints for such a strange behavior are very and very appreciated. Thanks!
(Perhaps it can help: All AJAX requests are performed with jQuery 1.4.2)
I'm very sorry, as I understood later, the question is not complete, because there was another pitfall I didn't mention, so no one couldn't answer the question in principle. The reason of the bug was hiding in the... <body onunload="..."> tag definition. That was quite unexpected, but that code contained some AJAX request that must be invoked when a user leaves the page. I only realized that the authenicating module (FORM, j_security_check) returned a response (HTTP 302) containing the Location header - so that was the reason why browsers did redirects.
The exact scenario was like that:
Open the page containing <body onunload="some_ajax_here">.
Log out the app using another tab so you could stay at the same page.
Refresh the page so some ajax could be invoked - this AJAX request is not now allowed because it's a secured part of the application (you get the forwarded content of the login page).
Enter the credentials and now oops you get to the result of some ajax directly in the browser window.
As the quick fix, and I hope the final one, I added another request following that AJAX request:
$.ajax({
async: true,
method: "GET",
url: document.location.pathname + document.location.search
});
So the HTML page script simply makes self-page request the last one - j_security_check returns the Location referring the last used HTML page, and the redirect works fine. Perhaps my explanation is not clear and may be not complete or even full of mistakes, but it looks like that in general. I'm very sorry once again, and thank you #ChristopherSchultz!
Related
The question is probably easily misunderstood, so I'll go into more detail:
I am trying to automate a task in a certain (very outdated) browser-based idle game that is written in PHP in order to polish my portfolio with a little more variated projects.
I used DevTools to reverse most of the requests and wrote a small C# Request wrapper to test them. I can get most of the actions I want to work, using the respective ajax get requests and the correct cookies/headers - not really part of the problem.
Example:
Attacking an enemy:
https://somebrowsergame.com/game/ajax.php?mod=location&submod=attack&location=3&stage=2&premium=0&sh=****mysessionhash****
Making a GET request to this URI with the correct headers and cookies, I can perform the in-game action programmatically and successfully from my C# console application and see that the fight has taken place when visiting the site in the browser.
The problem:
When monitoring all requests after clicking the "attack" button, via DevTools, even with preserve logs enabled, I don't see any redirects or way of determining how my browser gets told where to navigate to.
Findings
I found out that the button calls a javascript function attack() in its onClick event and tried debugging the javascript in DevTools in order to find out where somethign happens (such as setting document.href or smth), but when Debugging I ran into a seemingly infinite loop of setInterval handler and setTimeout handler in the call stack.
I also cleared the Network tab after the onClick event (and after the ajax request which I could find during Debugging) but the only request/response I got was the document GET request for the final page, no request telling my browser which site to navigate to.
Monitoring requests
The request made to initiate the action (via button click on website or ajax GET request as outlined above)
The document response / site navigated to
What I want to know is how my browser got told which site to navigate too, as the request URI for the document request (getting the html of the target page) has a parameter generated on the server side (logId)
I have also used "All" request types in DevTools, as well as negative filters when monitoring requests but never was I able to see how my browser knows which page to navigate to. I tried with source breakpoints at "beforeunload", tried inspecting the javascript source connected to the onclick event of the button (which didnt give me anything, as the js is minified and barely readable - i am not even sure if the navigation is done via window.target.href) and googled this question in all possible wordings which lead me nowhere
I am not too versed in web development, but I am sure my browser has to be told where to navigate to in some fashion after clicking that button?
I have my main container (app.blade.php) and inside it I have my home.blade, inside there is a container that refreshes with ajax after clicking an item in the sidenav menu. If you click one of those items when the session has expired, a middleware redirects you to the login (or at least it’s meant to). This should happen
God login
The issue is that, when that event happens, it renders the login inside of the container refreshed with ajax, like in the picture below. Any idea of how to solve this?
Bad login
(Sorry if i have issues in my writing, i am still learning english and in stackoverflow in spanish nobody helps :/)
Your "middleware" is working OK, it is doing what is meant to do: Any petition to the server is transformed in a redirection to your login page. However, you are making an async call. I guess you are rendering whatever the result is in a container, resulting in your "bad login".
A possible solution is to add some parameter to your ajax requests in order to catch it on the server side and send you an error status instead of a redirection, then in your page handle that error as a browser redirection to your login.
1) I saw an interview question on this, and I'm assuming it's something to do with form submission and avoiding double submissions. Can someone confirm this?
2) Assuming this assumption is correct, can this be done with Ajax? If so is there a link someone can point me to?
(I'm assuming you'd generate some sort of random number and include it in the form as a hidden field, then ensure that number hadn't been submitted before for the session).
Redirect-after-post is a technique to avoid problems with the user refreshing or using the back button to get back to a posted form. In short, instead of providing a response page to an HTTP post, which will trigger another post if its reloaded, you issue a 303 redirect (or a 302, to support ancient browsers by taking advantage of a bug that is as old as the web). This causes the browser to issue a second HTTP request - a get this time - and if the response page to that is reloaded there shouldn't be any problems. Just make sure that all the changes are made by the post handler and the page you redirect to has no side effects.
If you post using XMLHttpRequest then the redirect will be followed; unless you specifically support it using the hash part of the location or the new HTML5 history methods then the back button and reload aren't going to trigger an AJAX post again.
I have a page that gathers environment status from a couple of IBM WebSphere servers using iframes similar to this:
<iframe src="http://server:9060/ibm/console/status?text=true&type=server&node=NODE&name=ServerName_server_NODE"></iframe>
and it happily prints out "Started" or "Unavailable" etc. But if I load the same url in a normal browser sometimes it works, sometimes it does not? Some of them are showing a login page, while others are simply return HTTP code 500.
So whats the difference between loading the page through an iframe vs through a browser?
I can tell you that the iframe solution works no matter which machine I am doing it on, so I do not belive it has anything to do with the user whos opening the page. And before you ask, why not keep the solution that works, well its because it takes a long time to open the page with the iframes vs a page where everything is requested through ajax.
Update: Using jQuery to perform the ajax call returns "error" and "undefined" for the servers that I can't see in a normal browser.
One difference is an iframe has to render the view while XHR would not.
An iframe is essentially the same as opening with the browser. In both cases the browsers credentials are used, so there will be no difference between the two.
Secondly, loading something in an iframe should take the same amount of time as requesting it through XHR, since in both cases the browser makes an HTTP request and waits for the response. Although I should add that an iframe will take time to render the content onto the page. However if you plan on displaying it with ajax anyways, an iframe/xhr solution will be more or less the same.
In case of ajax request same origin policy (which restricts cross domain call) comes into picture. So you can't make cross domain call using xhr. Alternative for same is embed flex swf file in your page as activex control and make flex call through javascript and then flex is responsible to make cross domain call (flex can if targeted domain allows cross domain using crossdomain.xml) and renders result using javascript again.
Greetings,
Here's the problem I'm having. I have a page which redirects directly to another page the first time it is visited. If the user clicks 'back', though, the page behaves differently and instead displays content (tracking session IDs to make sure this is the second time the page has been loaded). To do this, I tell the user's browser to disable caching for the relevant page.
This works well in IE7, but Firefox 3 won't let me click 'back' to a page that resulted in a redirect. I assume it does this to prevent the typical back-->redirect again loop that frustrates so many users. Any ideas for how I may override this behavior?
Alexey
EDIT: The page which we redirect to is an external site over which we have no control. Server-side redirects won't work because this wouldn't generate a 'back' button for in the browser.
To quote:
Some people in the thread are talking about server-side redirect, and redirect headers (same thing)... keep in mind that we need client-side redirection which can be done in two ways:
a) A META header - Not recommended, and has some problems
b) Javascript, which can be done in at least three ways ("location", "location.href" and "location.replace()")
The server side redirect won't and shouldn't activate the back button, and can't display the typical "You'll be redirected now" page... so it's no good (it's what we're doing at the moment, actually.. where you're immediately redirected to the "lucky" page).
I think the Mozilla team takes a step into the right direction by breaking this particularly annoying pattern. Finding a way around it somehow defies the purpose, doesn't it?
Instead of redirecting on first encounter, you could simply make your page render differently when a user hits it the first time. Should be easy enough on the server side, since you already have the code that is able to make that distinction.
You can get around this by creating an iframe and saving the state of the page in a form field in the iframe before doing the redirect. All browsers save the form fields of an iframe.
This page has a really good description of how to get it working. This is the same technique google maps uses when you click on map search results.
I'm strongly in favor for the Firefox behaviour.
The most basic way to redirect is to let the server send HTTP status code 302 + Location header back to the client. This way the client (typically a browser) will not place the request URI into its history, but just resend the same request to the advocated URI.
Now it seems that Firefox started to apply the bevaviour also for server responses that try redirections e.g. by Javascript's onload event.
If you want the browser not to display a page, I think the best solution is if the server does not send the page in the first place.
Its possibly in aide to eliminate repeated actions.
A lot of ways people do things is
page 1 -> [Action] -> page 2 -> redirect to page 2 without the action parameters.
Now if you were permitted to click the back button in this situation and visit the page without the redirect, the action would be blindly re-performed.
Instead, firefox presumes the server sent a redirect header for a good reason.
Although it is noted, that you can however have content delivered after the redirect header, sending a redirect header ( at least in php ) doesn't terminate execution, so in theory, if you were to ingnore the redirect request you would get the page doing weird stuff.
( I circumvent this by the fact all our redirects are done via the same function call, where i call an explicit terminate directly after the redirect, because people when coding assume this is how it behaves )
In the URL window of firefox type about:config
Change this setting in firefox
browser.sessionstore.postdata
Change from a 0 to 1