Hi I'm facing an issue that, onclick on hyper link calling script funciton which opens the URL in window.open.
In netwrok tab Noticed that URL request is sending twice, for one reposne code is 302(doesn have nay response data) and for another one response code is 200(which has reponse data), This behaviour in Microsoft edge browser.
In internet explore noticed behaviour is different, on click on hyperlink seeing request is sending twice, both requests are getting succesfull with response code 200 with proper response data.
Below is the code I've done so far of the Hyper link. Can some one help me why multiple request are triggering how to fix this to trigger only one request.
<a tabindex="13" title="This link will open a new browser window that contains the user details."
onclick="javascript:openChildWindow('http://xx.xx.xx.xxx:xxxx/xxxx/channel/session.cgi?sessargs=p47iorSBMUG1tKkTcNpjM4qNdGTees3H');return false;"
href="http://xx.xx.xx.xxx:xxxx/xxxx/channel/channel/session.cgi?sessargs=NliOOYGLmDf1yePDXopw8o2IMx2HYyg1">View details</a>
In some cases, a url redirects to another url while downloading an application. This we can easily identify while hitting the url in browser. But how to make this possible in code to download the application from the redirected URL using TDownLoadURL.
For example by hitting http://www.skype.com/go/getskype-full on Internet Explorer we get a redirected URL as https://download.skype.com/2292017409dc8d2781c7c2d4c1e4c1bc/SkypeSetupFull.exe
i have used idHttp.post() to login inside a site
then i posted my information to the download page which is something like an archive (needs start date, end date and etc) and then sent submit button post
when i open the final response code (after posting submit) i can see the links for download, but they are something like :
__doPostBack('DG_FileList$ctl03$LB_Download','')
after i click on the link (manually inside a browser), http analyzer shows another post like this :
__EVENTTARGET DG_FileList$ctl03$LB_Download
and i get redirected to a download.aspx page and download starts in the browser
i tried to Post this like other informations but i got an error for response code, am i doing something wrong ? can i even run the _doPostBack with post method ?
if not, what can i do ?
Thanks.
Nothing fancy here, but I'm on it since one hour with no success.
I'm trying to load my RoR root page welcome#index inside a Facebook canvas app.
My welcome#index is empty (http://sitlux-contact.herokuapp.com) and work well when url is copy-pasted in search bar
On Facebook, I set an "App on facebook" app with theses settings:
Canvas url: http://sitlux-contact.herokuapp.com/ (note that the last "/" is requested by Facebook)
Canvas secure url: https://sitlux-contact.herokuapp.com/
This is my Facebook canvas page url:
https://apps.facebook.com/sitlux-contact
Heroku page is working perfectly when direct url is used in browser, but generate a "The page you were looking for doesn't exist." when I'm trying to load it inside the canvas app.
Any clue on this would be very helpful. Thank you in advance. KR
Debugging your facebook app page using Firebug net panel saw that facebook is requesting your app url with a POST request. I've received the same response using this curl command
curl --data "fake_param=fake_value" https://sitlux-contact.herokuapp.com/
I think you should handle POST response to clients.
My organization had a web app that worked perfectly in iOS 6. You'd visit the website, the website would tell you to add the page to your homescreen, and boom, a nice HTML5 web app was added to the home screen.
Because we're processing sensitive data, the web app used HTTP authentication (via the native WebKit auth dialog) to authenticate user/passes. It worked without a hitch until iOS 7. Now when someone tries to summon the HTTP auth dialog, nothing happens. It's clearly trying to load something, as the spinner in the status bar appears, but no dialog ever pops up, essentially breaking the "app."
Has anyone else run into this? Is this something you'd consider to be a bug on Apple's end? Any workaround?
My company ran into this last fall, starting with iOS 6, and what we have been able to ascertain is that it is a genuine Apple Safari bug as part of its security "enhancements". No real explanation from them for rationale, but here is what we see in the debug and packet sniffers.
In normal operation, the Safari browser will request a page (or an object in the page) from the server on a GET. If that asset is protected with an Access Control List, in our case Apache Basic Auth, and it is the first request on that host in the session, the server will respond with a 401 HTTP response header indicating to the client (the browser) that it needs to request again, this time adding a basic auth header that has authorization credentials. The browser then presents a login dialog to the user, where they can enter user and pass credentials, and either submit or cancel the request. On submit, the client re-requests with those credentials in the auth header.
Assuming the credentials are accepted on the second GET request, the proper asset will be returned on the response, and the document in the browser will proceed with loading the rest of the page (assuming it was a page you requested). If you have embedded assets that reside on a different host, and that host requires authentication for that asset, the process is repeated as the page loads.
Here's where it gets broken. If you embed calls to objects from more than 2 hosts total on the same page, which require basic authentication, the 3rd authentication prompt on that page is suppressed, so the browser spins forever waiting for you to enter credentials on a prompt that you never see. Your Safari browser is now hung up on that stalled authentication prompt, on this and any other tab, even on a reload, and you will not get another prompt unless and until you hard-close your browser or restart your device.
This does not affect Chrome, just Safari, and it is both on an iPhone and an iPad with iOS 6 or later. I have the latest iOS version as of this writing (7.0.6), and the problem is still there.
We had a workaround last year, where we would create an internal page that had an array of each of the embedded hosts, which we would then loop through with an iframe embedding a call to the favicon.ico at that host's location. That worked until recently, where now, perhaps because of the iOS 7 feature of freezing background tabs, the auth prompts are frozen up again.
Here was the JavaScript sample:
hosts=["store","profile","www","secure-store","images","m","modules"];
devhost=location.hostname;
var i=0;
while (hosts[i])
{
newhost=devhost.replace('store.mydomain',hosts[i]+'.mydomain');
document.write("<iframe Xhidden seamless=seamless width=0 height=0 src=http://"+newhost+"/favicon.ico><img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src=http://"+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br></iframe>");
document.write("<img height='16' width='20' alt='NOT' title='NOT AUTHENTICATED' src="+(newhost.indexOf('secure')>0?'https://':'http://')+newhost+"/favicon.ico> Authenticated on "+newhost+"</a></br>");
i++;
}
The second set in the document.write would give a visual indication of which hosts have been authenticated, as their favicon is now displayed. It also lets you know which host might be stalled, as its icon is missing.
Since this workaround stopped working on iOS 7, the only cumbersome solution we have is to pre-open a separate tab for each of the favicons (directly in the URL), enter the auth, go back, go to the next one in the list, and repeat until you have cached all of the auth credentials for all of the hosts used on the page. At that point, you can load the original page since your creds are now cached. Cruddy, and completely unreasonable for an end consumer, but is what we need to do for testing sites that are behind a public CDN, as we need to protect assets on that development site with an ACL.
As of today, we are still figuring out a better workaround. Not an issue on Android, Windows, or any other iOS.
Sure worked better when Jobs was alive.
Hope some of this helps.
I have the exact same problem. Basic authentication worked with previous iOS versions but not with iOS 7 in combination with web apps added to the home screen. I think this may be related to the dialog problem described here.
Standard dialogs are not working at all, such as alert, confirm or prompt.
The login prompt that is shown to authenticate the user is probably blocked (does not work or is not visible) and that is why the web app does not pass through the authentication phase.
I suppose Apple will have to fix this bug in a future release.
Edit: After upgrading to iOS 7.0.3 basic authentication suddenly started to work again also in home screen web app mode. Login prompt is displayed and everything works as expected.