My client's website opens external links in new windows (with target="_blank"). The links are also routed through a logger which responds with a 302 redirect to the desired page.
For example, instead of
...
We have
...
Where /redirect?to=$url returns an HTTP 302 to $url.
This works fine in all browsers except IE8. Instead of opening a new window with the desired URL, IE8 opens a new window and stalls with a progress throbber and an empty address bar. If I then hit stop and reload, the desired URL loads.
Has anyone encountered this problem? Is there a known solution that preserved my client's desired behavior? That is, to open links in a new window with redirect-based logging.
I know it's just a workaround, but... use JS redirection if the browser is IE8?
Watch your traffic in a network traffic debugger like Fiddler2 to see what's happening on the wire. You can then add the exact raw text of the HTTP response to your question to help with replicating your results.
Also, is this redirection crossing between IE security zones (e.g. Internet,Intranet, etc)? In particular, it's always interesting if a redirection crosses (Vista+) from a Protected Mode Zone to a non-Protected Mode zone, as this goes through a rather obscure codepath in IE.
Related
.
In Chrome's developer tools, under the "Network" tab, I can see redirect paths and HTTP status code if I check "Preserve log". See image above, where you can see the domain ap.no redirect to
www.aftenposten.no and returning a status code 301.
My problem is that it doesn't work for all sites. Are there situations where Chrome will not be able to know that a redirect has happened?
One example is amazon.com, which redirects to www.amazon.com, but I cannot see the redirect in Chrome's developer tools.
Is there another way to see the redirect info in these cases where Chrome doesn't seem to pick it up?
Try these methods to get around the issue (in order of complexity):
Use an incognito window when you load the page.
Use the extension "Cache Killer" to disable caching of data.
If all else fails, clear all browsing data from Chrome.
In this instance, only clearing browsing data helped, but I regularly use Cache Killer and incognito window when I am testing my own websites.
I'm getting a strange issue only Chrome + Firefox. It doesn't repro on IOS or IE9.
Here's the repro:
Load Home page http://example.com
Login (via a rel="external" hyperlink). In my case I use Facebook's Oauth Server Side flow - so this URL is a facebook.com.
Facebook accepts the user's credentials and then redirects to http://example.com/user/callback. Here various facebook data is processed (it is provided in the query string).
The server side code at http://example.com/user/callback then redirects the user to http://example.com. The mechanism used for the redirect is a RedirectToAction from ASP.NET MVC3. This returns a 302.
Expected Result:
User would see a URL in their browser = http://example.com and the content all nicely shown. This works on IE and Safari.
Action Result (on Chrome Only)
User gets a URL in their browser = http://example.com/#base_domain=example.com
The actual page is blank (no visible content)
However a view source reveals that the content is present.
Action Result (on Firefox Only)
User gets a URL in their browser = http://example.com/#_=_
The actual page is blank (no visible content)
However a view source reveals that the content is present.
Additional Info
If I enter the URL http://example.com/#base_domain=example.com into IE I get the same 'hidden' content (i.e. blank page with HTML source still present).
I should also note I use the RedirectToAction/302 redirect technique in other parts of the application with no issues whatsoever.
The issue also repros with AJAX navigation turned off.
EDIT: This also works on Safari (OSX + Windows) with no issues. It's only apparently broken on Chrome + Firefox on both Windows and PC.
IOS/Safari: OK
Win/Safari: OK
Win/IE: OK
Windows Phone Emulator: OK
Win/Firefox: borked
Win/Chrome: borked
OSX/Safari: OK
OSX/Firefox: borked
OSX/Chrome: borked
Not sure about Android.
The best solution appears to be setting the Push State and Hash Listening to false - so chrome/ff completely ignore them. I already had AJAX navigation disabled (there some interesting behaviours with it I hadn't completely accounted for yet with my server side code).
$.mobile.pushStateEnabled = false;
$.mobile.hashListeningEnabled = false;
I'll probably wait for 1.1 and stabilise the rest of my code before trying to get AJAX navigation working.
Problem
I have an application driving a tab on a client's page. The application works correctly if the user has not enabled FB's "secure browsing" feature. If attempting to view over HTTPS, the iframe doesn't even appear (no errors, no mixed-content warnings). When correctly loading over HTTP, the div with the id "pagelet_app_runner" has an iframe inserted into it and the application content is loaded inside there. Over HTTPS, this div remains empty and the iframe is not inserted into the page. There are no Javascript errors appearing in Firebug or Chrome's equivalent console.
Why I'm Asking Here
The host has a valid SSL certificate and there is no 'mixed content' at the URL in question. I can successfully view the content over HTTP or HTTPS by visiting the URL directly, and I can do the same by visiting apps.facebook.com/canvasURL/tabURL. It is only when attempting to view within a Page Tab that the HTTPS load fails as described above. My application is configured with both regular and secure canvas and tab URLs.
Attempted Debugging
I've recorded some sessions with Charles but since the iframe isn't being inserted into the page, I think I'm coming at the problem after it's already occured. I'm no Charles expert so happy to be corrected here.
Apache isn't seeing any request (in either regular or ssl logs) for the affected loads. non-SSL loads come through as expected in access_log.
Plea for Help
I'm out of ideas for debugging this. Does anybody have any suggestions? What really obvious and stupid mistake might I have made? :)
edit: nicer formatting
Your app canvas URL is https://skinnycomp.nextstudio.com.au/skinnycowcomps/ , which send 404 error to Facebook proxy (request is going through proxy when viewing app via tab), also when viewing your app via apps (https://apps.facebook.com/122381834451561/), again 404... maybe Facebook proxy is ignoring 404 and posting blank...
Try changing canvas URL to https://skinnycomp.nextstudio.com.au/skinnycowcomps/tab, also you can check if your app is accessed via page tab, in signed_request there should be page_id...
23:51:15.379[549ms][total 1667ms] Status: 404[Not Found]
GET https://skinnycomp.nextstudio.com.au/skinnycowcomps/
This is a real longshot since I'm sure you've triple checked all the settings, but the blank page can happen if an invalid url is specified in the Page Tab URL field in the app settings. Since it only happens on https, it would imply something specifically with the Secure Page Tab URL entry. It might be worth checking that again, and maybe even re-saving it or changing it to something else to see if it helps.
I was using relative URLs for the regular and secure tab URL fields. From memory relative URLs here were mandatory at some point in the past. It appears now that a relative URL will still work for HTTP but not for HTTPs. Fix: absolute URLs. Hopefully FB update their field validation to match what's required too.
How can I open an url in the current active browser which is been provided as a part of the mail
Example- I receive an email in my outlook.I am browsing also.If I click on the url provided in the email it must open in the current browser window which is open
I don't think that is possible with a URL. The handling of http: protocol is operating system dependent, and really shouldn't be messed with.
My default browser is FlashPeak SlimBrowser and with this as my default browser it isn't a problem since this is what it does by default. I use SlimBrowser since the web site I work on is keyed to IE and SlimBrowser uses the IE Object with any of the automatic IE junk disabled. No question about popups since they don't happen unless I click on them.
The click interface in outlook is using the API to open the default browser window. The default browser determines how it is going to handle the request.
I have an MS-Word document with a hyperlink. The hyperlink points at an authentication redirector on my server. When I control-click on the hyperlink, my server logs report that it
does a fetch with IE, then
fetches the redirect url with IE, then
launches the "default browser", which is Firefox in my case, and re-fetches the second (redirect) URL.
What gives? Is this by design?
I noticed this because my auth system is currently dependent on cookies set by the redirector. I have some ideas about using url-based auth for this bit, but I need to know what is motivating Word's behavior first.
I have some guesses but I'm looking for something authoritative (or at least a better-informed guess).
Unfortunately, yes. And they try to blame it on "a limitation of the single sign-on system used by the web server"...
http://support.microsoft.com/kb/899927
Actually, this is a "feature". If the hyperlink is to a Word document, word will attempt to download the document and open it. (You must be thinking it's IE because of the user-agent, but the request is coming from WinInet in the the Word process.)
The mess comes about when the server doesn't respond with a page, but rather responds with a redirect and cookies. Word follows the redirect to see if it's going to get a Word document, and it eventally ends up with an HTML page. It then decides that Firefox should display it, so it launches Firefox with the final redirected URL, (but without any of the cookies that the server sent).
Firefox may end up needing those cookies, if this is an SSO sign-on.
Late addition:
Noticed the same problem. Here with MVC 4 it caused the loss of querystring information.
Word launches the browser only after it receives a Http 200 status.
So I avoided this by checking in the controller whether the request comes from IE7 (representing likely only to be MS Word) and returning a 200 manually.
Then the 'real' browser will re-send the http request and all's well ends well, since from there the request is processed normally and all information is retained in the session with the 'real' browser.
Bit of a workaround, but hey, it works. And it's only for a small amount of requests (in our case).