i have a web view and one of the sites it may display contains a form with various submit-buttons. Now the problem is that when the customer looses and regains connection while on this site, none of the submit buttons seem to work anymore. The request is being sent(decidePolicyFor navigationAction is called) but then nothing happens...
When using the normal chrome browser it worked fine.
I could repoduce it while being in their (guest) network, but not at home in my private network, even with giving the device a different ip address...
edit: after overwriting didFailProvisionalNavigation i noticed that it does get called with the error "The Internet connection appears to be offline."
But normal links work and i can't reproduce it in the other networks that i have access to
Related
I want to highlight an issue that I am encountering with video indexer. On my machine, whenever I try to login to video indexer ( either microsoft or gmail account), it shows me blank dashboard like the one below:
I have tried running it on other browsers and incognito as well (clearing browser cookies too). But nothing works on my machine. However, the same works fine when I log in through my other machine. Any help will be appreciated.
Make sure you try incognito mode without any browser plugins/extensions.
Can you open the browser console and see if you are getting any errors or network issues?
Looks like the GRAPH API is hitting a 401.
This is used to return the currently logged in user.
Since you are saying it is working in another machine fine.
The possibility I can think of is because of Conditional Access Policy(Location based mostly).
There could be some policies(for Security) that can be set at the tenant level which is making the Graph API to error out with 401.
The one machine is within the compliance (trusted network/vpn/domain joined etc.) where as the other one is not compliant. Hence the error.
Well, This is the thing, I was navigating the internet any page, and suddenly, A Pop Up windows appeared on screen from my ISP (To remind me I didn't pay today) ... so Do you know how to send that kind of messages without opening the webpage or installing anything on a pc?
I was navigating the internet any page...
Since your internet access is through the ISP, they have the ability to manipulate the traffic coming through their hardware. This includes replacing the content of a site, appending content, or inserting content.
Obviously they can't alter the actual site, but if you request "foo.com" and you haven't paid your bill, they can return whatever they want in response to your request.
They could return <script>window.open()</script> + the HTML content of "foo.com". Invalid, but browsers will render it. They could return a warning page. They could return an HTTP status code. You get the idea.
If you didn't have your web browser open, then something is installed in the background (whether or not you know it). Most hardware comes with dozens of background services which try to be "helpful".
Our customer has Single Sign On implementation with Shibboleth. that post assertion back to our server on cloud. it works properly in IE, Chrome, ... but always fail on Firefox recently.
The error is famous "The connection was reset", I searched lots of discussion about this error, and found a workaround by change Firefox security setting as following:
open the firefox, clear all the cookies and caches, then point to about:config
search and set both “security.ssl3.rsa_aes_128_sha” and “security.ssl3.rsa_aes_256_sha” to false (by double click these item in the about:config window)
After change above 2 security settings, the issue is solved in firefox, everything is ok. But we can't suggest our customer to change their Firefox security setting. I am wondering why above two items caused "The connection was reset" error, can we have a solution on our server or Shibboleth ID server?
Really appreciate any suggestion.
I just experienced the same problem but with SimpleSAMLPHP. The problem was only in firefox and only on the postback of the SAML Response.
For us the reason for the error was that out LB had a cap on how much data it allowed in the header. Firefox adds more header data than the other browsers and the SAML Response was big enough to reach the cap.
After changing the cap, everything works fine.
So I just launched a re-designed website on a new server. It's been 48 hours since the site migration from the old server to the new server. I just added Like buttons to news entries and for some reason they're not showing up on a users wall when clicked on. If a comment is entered in the drop down (after clicking Like) and the Post to Facebook button is clicked, then the comment shows with a URL to the page--no title, no description text, etc. The only thing I can think is that Facebook for some reason has the old website DNS cached which of course would lead to unavailable URLs.
Anybody experienced this? Normally Like buttons are super simple to implement, but these one are being stubborn.
Either Facebook DNS hasn't propagated or their cache is old.
You can clear FB's cache by putting in your url in here: http://developers.facebook.com/tools/debug
I have a local site (IIS6, although similar issue with a totally different site using IIS5.1) which uses integrated windows authentication, from what I can tell - using IE7 if a user enters the URL into the address bar, everything works OK and the user is logged in automatically. However, if the user clicks on a hyperlink within an e-mail (using Outlook), the site opens but the user gets a login prompt - when details are entered everything then works fine.
Can anyone explain why this is the case? I should say it's actually very temperamental, sometimes the above occurs, sometimes it doesn't... any help is appreciated.
cheers!
Are the urls of the two cases identical? If there is a . in the url, IE will not attempt to pass the user credentials to the site, and will therefore not automatically log you in.
Example: http://mysite/page.aspx is different from http://mysite.domain.local/page.aspx, even though they might point to the same server.
If Outlook is launching using the domain.local, you will get the behaviour you describe.