I have apache authentication set up on a wordpress multi site instance, it works fine in firefox and chrome, you type in the username/pass once and then you can happily visit any page on the site. Unfortunately this is not the behavior in safari. Every time you go to another page, you must re-enter your credentials.
Is there some way I can look at the security exceptions for safari and set it to always trust the certificate or find some other setting to not ask for authentication on each page?
Related
We have a program that runs in IIS with Windows authentication, and which is available to the outside world.
Right now, we provide to every interested party a link to the program, along with guest credentials they then have to type.
Is there a possibility to do away with the credentials? Our internal people should be able to login as usual, but we want to provide a link to get into the guest account without typing any login credentials.
I have tried to add the credentials into the clickable url, but Internet Explorer and Edge browser do not support this, and Mobile Safari throws phishing warnings.
Can this be done universally, that the authentication is done invisibly in the background in all browsers, using some kind of redirect or XHR call with arguments or something like that?
Running WAMP and I'm trying to embed an iframe of an external website (mcmaster) in a dokuwiki and I'm getting a security alert that doesn't allow the site to be displayed. Security alert says the sites certificate isn't good, and I didn't get the option to allow the page in the iframe but if i opened in a new window i got the option to. So after allowing it just returns a blank screen. What do I need to enable or exception to add in Apache to allow the server to embed this website? Apologies if this is in the wrong stack but I assume this is a server issue not a coding issue, as other sites work fine with the syntax.
I've implemented a simple OAuth2 for Authentication login system that is working reliably on my dev server using a localhost redirect uri.
When testing from a production server, with updated redirect uri, the Google account permission interface opens up for the user logging in. After authorizing account access, the browser just hangs on "Waiting for accounts.google.com..." and doesn't go anywhere. At this point, I can see that the application has been granted access to my profile by viewing account permissions on my Google account dashboard.
If I change the redirect uri to an invalid one, I do get the invalid redirect uri Google error message back, so it looks like the redirection cannot reach my redirect uri. I can reach the reditect uri directly through a browser though. Any pointers?
Had a similar problem trying to create a "Login with Google" App. Since this was my first Google App, and I was also just first using the social networking setups in the software package which I bought BEFORE the Google API had changed, I was at a complete loss as where to start.
It finally dawned on me to redirect Google (via the App settings in the developer console) to a test web page on my site (instead of the page defined by the software package,) and all worked as expected, meaning Google redirected properly to the test page (which was actually just my root index.php). This told me that because the Google API had changed, my software package functionality was obsolete, and I needed to explore the code there.
I have a mvc4 web app that sits behind ADFS 2.0 authentication, it's configured using the web.config file. The application can be visited by going directly to a URL or as an iframe inside of CRM 2013.
The application works in all (tested) browsers when visiting the URL directly, both redirection to login form and handing the user back to the web app with the proper information in the ClaimsIdentity.
However, when visiting the app as an iframe inside CRM2013, internet explorer goes into a continous login loop. You are asked to provide the credentials (which are the same as for logging in to CRM) and when you click ok you get redirected back to the same login page again, to my knowledge the app never receives the hand off.
In Safari, Chrome, Firefox, and Opera the users are able to log into the application inside of CRM as well as outside without any problems (I'd even go as far as saying that it works better than expected for these browsers).
Does anyone have any idea of what I can try or what the problem could be for IE?
EDIT 1
I'm thinking it has to do with some security setting and am playing around with the settings in IE. Unchecking this box stops the login form from showing in IE at all and I get an empty page instead.
Is the iFrame on the same (sub)domain as the site inside? You can use Fiddler to view your redirect flow, are the cookies added as expected?
I've seen cookies that are overridden by the iFrame host, in that case you lose the auth cookie. Browsers react differently on same domain cookies.
Another problem might be X-Frame-Options, do you see any warning in the F12 console of IE?
I have two WCF WebHttpBinding-bound self-hosted services. One is set to WebHttpSecurityMode.TransportCredentialOnly and HttpClientCredentialType.Windows. The other is set to None and None.
This service is serving the exactly the intended authentication prompt behavior on Chrome and IE, with correct content types and content. Testing on localhost and remotely (not on a domain). In IE, the default settings for integrated authentication send my credentials immediately to the authenticated service. In Chrome, the default settings prompt me for my windows authentication credentials.
But in Firefox I get no such prompt - just an error in Firebug of 401 Unauthorized and a blank page otherwise. I assume iOS has the same 401 Unauthorized problem, although the debugger console doesn't show any errors - I just get a blank page.
I don't know how relevant the WCF WebHttpBinding is versus a standard IIS-hosted website, but all the other googles I find are about someone trying to STOP the Windows Auth prompt in favor of Integrated Security mode in non-IE browsers. I kind of have the opposite problem - it's not showing up for me.
Is there something nuanced about the webservice response that Firefox and Safari are sensitive to that Chrome and IE are not sensitive to?
I'm testing on Windows 8 with IE 10 and the latest releases of the other browsers at the time of writing.
Thanks!
If I set it to HttpClientCredentialType.NTLM then all browsers work. But as I understand it, NTLM disallows the more secure Kerberos domain credentials (if they're available). I don't want to force a less-secure option!
Kerberos works well with IE and since Chrome shares stuff with IE, it works for Chrome too. For Firefox, you have to enable it. See here. Safari on Mac OS should work but not sure about other OS'.