After having had a hell of a time to make SSL works on Qt with windows, most HTTPS website seem to be working. Untrusted certificate are now added when required and such, well everything is fine ... BUT I can't login on reuters.com for some weird reason.
Take a QWebView, add a bit of magic to handle ssl errors that shows up, go on reuters then click on sign in.
Then something weird occurs. First of all, it requested acceptance of untrusted certificates, which ain't that weird. But then, once that is done, nothing happens. QWebView waits and never send the loadFinished(bool) signal. More over the web page displayed doesn't change.
When I try to do this on Firefox or IE, it tells me that there is mixed content on the webpage. Could it be the problem?
Related
Firefox seems to fail on registering a ServiceWorker for Push Notifications, with an error "InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable", but the code works in Chrome and Edge, and appears to be compliant with the examples online and the spec.
I've thrown an example up on one of my test sites, https://wiegandtech.net/ - visiting it in Chrome will prompt for permission and then opt-in successfully, sending the info to the server. But Firefox prompts, doesn't complete the registration, and doesn't fire any error or throw anything into the console. When I try to debug, it seems to never return from navigator.serviceWorker.ready.then call - I debug in and reg is undefined, even though the promise says it shouldn't be. I can find no reason why this is failing. I do see in Fiddler that FF gets the worker file, so it appears to be starting the call, but never finishing? The worker is valid JavaScript, as far as I can tell. Does anyone have any documentation on how Firefox's implementation is different from Chrome's/the spec?
Firefox requires the ServiceWorker's URL to end in .js - I was using an ASP.Net site and returning javascript but through my own controller. When I just give it the URL for the .js file itself, it now works. Would file a bug, but too non-trivial to setup a site given that ServiceWorkers require a real life site to troubleshoot, and their source code doesn't appear to be on github.
The web app that I am building in meteor works in chrome and I.E.(Other than a UI bug in I.E.) but it starts acting strange in Firefox. When I run it on my localhost and on the deployment to meteor.com, I don't get any errors in the console in the browsers' developer tools.
When I run it in Firefox, things start acting weird. On Mac OSX, if I run the app on my localhost and open it in FF it is just fine. However, when I open up the app that deployed to meteor.com via meteor deploy [my-app-url].com, I get the following errors but I can still use everything in my app:
Error 1:
mutating the [[Prototype]] of an object will cause your code to run very slowly;
instead create the object with the correct initial [[Prototype]] value using Object.create
Error 2:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource
at https://ddp--3071-[my-app-url].com/sockjs/info?cb=v9pygo9mzn.
(Reason: CORS request failed).
While right now I am not able to figure out what is causing the first error, I am mostly worried about the second error.
When I open up the app from it's deployment in FF on Windows 8, I get the first error once, and then I get the second error repeatedly and the app never loads(it just stays on my loading template from the iron router). My deployed app runs just fine on Chrome and I.E.
I don't send any kind of request to another server in my app, so I am not sure why I am getting a CORS request error. I have not set up SSL or began to make a certificate yet, so I am not sure if this could be causing this kind of error in FF as I got another exception on my login page in FF on my localhost saying that I shouldn't have password elements when I'm not using https.
Does anyone know what could be causing this?
Sorry that I provide any code, as I don't know what code I would post to solve this problem since I don't actually request anything from another server in code that I have written.
Thanks in advance for any responses!
If anyone is interested, it seems as if my combination of the aldeed:collectio2 package and one of my other packages was the cause of my problems. I removed this package and my issues went away.
I'm developing a Rails 3 app, and I noticed that when pressing Back, the browser re-shows the page it already has in memory, instead of hitting the server.
That said, I'm 99% confident that in previous apps I've developed, this wasn't the case, and the browser would hit the server again.
So, provided I remember correctly, this must be some HTTP header / something that Rails is setting to makes things snappier.
I'd like to know what it is since this is kind of problematic for us in pages where we modify the DOM heavily through JS, and the user ends up pressing Back and getting the "original" version served, instead of the heavily modified one, which is really confusing in some cases.
EDIT: I thought doing this had fixed the problem, but it didn't:
def force_no_cache_on_back_button
#expires_in -1, :public => false
headers['Pragma'] = 'no-cache'
headers['Cache-Control'] = 'no-cache; no-store; private; must-revalidate; max-age=0'
headers['Expires'] = 1.day.ago.to_s
end
Surprisingly that does work over HTTPS with a broken SSL certificate (we use self-signed for our staging server), but it doesn't work in production, with a "good" SSL cert. Which is just weird.
Any other ideas?
Thanks!
Daniel
I have an application using Janrain Engage for login.
Everything works since few months, except on ONE machine from Firefox...
I have no clue for what reason, when I try to log-in from this machine (on my site or even on Janrain's admin site), I get the sign-in page, the I choose a provider, enter my information, validate and then, nothing happens !
Normal process trace is:
GET
https://XXXXXXX.rpxnow.com/signin/get_login_info?widget_type=auth&provider=google&time=1358864872301 [HTTP/1.1 200 OK 1144ms]
POST http://XXXXXXX.rpxnow.com/redirect?loc=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy [HTTP/1.1 200 OK 2533ms]
POST https:// my_token_url_on_mydomain [HTTP/1.1 302 Found 3667ms]
On the faulty machine, I just have the first GET, and then nothing else...
The token_url callback is never called, so I even do not have any trace on my server.
The machine where the problem occurs is my personnal machine at home. Same login attemps works like a charm with Chrome or IE. I did'nt find any specific settings in my Firefox configuration.
I'm afraid some potential customers can get the same behaviour as me and go away... Is anyone experimenting similar problem ?
Froggy. You might have 3rd party cookies disabled in Firefox. That's the only thing I can think of that would cause that issue on a single browser. Go here for info on changing that setting: http://support.mozilla.org/en-US/kb/disable-third-party-cookies/
My command line testing tool, which uses NSURLConnection, is interfering with Safari's cookies. How do I stop this from happening?
Here's what I'm seeing:
I log into the web site in Safari.
I run my command line based sync tool.
The sync tool logs in, and gets several pages of data. For each request, the cookie rolls over. (The sync tool does not log out.)
I return to Safari and click a link. The link returns me to the login screen.
If I skip step 2-3, the link in Safari works correctly. My tool is clearly the cause of this.
I'm creating my connections like this:
_connection = [[NSURLConnection alloc] initWithRequest: request
delegate: self
startImmediately: NO];
I'm not doing anything explicitly to the cookies, but just letting the default code handle them.
I'm not sure what's really happening here. If Safari and my app really shared the cookies, wouldn't Safari's copy of the cookie also be rolled over? While weird behaviour, everything would work and I wouldn't even know what was happening. This is something else.
Anyway, how can I stop my command line tool from logging people out of their session in Safari?
Seems like the right approach here is turning off default cookie handling entirely, so it doesn't touch the shared store. You can use -[NSMutableURLRequest setHTTPShouldHandleCookies:NO] to disable the default behavior, then read the cookie headers out of the responses, store them yourself, and insert them back into subsequent URL requests as appropriate.