I have a custom mdm solution running for IOS.
during enrollment, I am using HTTP basic authentication to pass the user name and password to be verified against our db/AD.
if the user is denied access, I send a 401.
however, on the IOS side, it pops up an error that says "safari could not install a profile due to an unknown error". Seems like a pretty bad error where I want it to say access denied.
Also there's an issue that safari decides to cache the credential used, so I don't get a chance to re-enter the user/pass again unless I clear all the cookie/cache data.
Anyone have met this issue before?
Looks to be issue with my code.
I've sent a 401, but actually the specification calls for a WWW-Authenticate header to be sent as well. With that added it, it's working normally now.
Have you considered using a more widely tested MDM solution such as AirWatch? A solution such as this has integration with AD and would be an excellent option for you to evaluate.
Related
I've created an app using react native and which is using an IdentityServer 4 server to for authentication. I'm using react-native-app-auth to perform the authentication.
When I click login the app tries to open the Identity Server login page in Safari and iOS shows a standard dialog to say:
"myApp" Wants to Use "myIdServerUrl" to Sign In.
The problem is, where it should say myIdServerUrl, it actually says (null) as you can see in the screenshot.
Does anyone know why this might be? I'm not sure if its something I've misconfigured on the app side or something I'm not sending back from IdentityServer that I should be. I would have thought it would have just shown the URL that I'm requesting but that's not the case as the login page opens correctly when I click continue, so I haven't provided a null URL or anything.
If anyone knows where iOS looks when populating this dialog that would be a great help.
Thanks a lot!
EDIT
After a bit more investigation I've found that a CONNECT request is made to the Identity Server before showing the dialog. This suggests to me that the data it's using is somewhere in the certificate as the CONNECT request is where an SSL connection is requested for HTTPS sites. I'm still not sure what field I'm missing though. I have the Subject Alternative Name populated so I'm not sure what else it could be looking for.
EDIT
It seems, if the URL has a recognizable top-level domain, the domain name (as defined here) will be reported by the dialog. For example, some.host.name.zw will be referred as name.zw and video.google.co.uk as google.co.uk.
Otherwise, ("null") is produced, as in case of some.host.name.local, etc.
It is still an empirical finding, I don't have any official reference to this, but one that is easy to test.
Since 2AM (ish) this morning, the SSO does no longer work with LinkedIn.
We 100% get the error "the authorization server encountered an unexpected condition".
We did not change our code whatsoever. We tried to switch the LinkedIn developer app to test mode and then back to live mode, but still no luck.
There can be no logs on our end (for the issue is on LinkedIn end), and AFAIK there is no developer log on LinkedIn either (although it could be a pretty useful addition).
Anyone experiencing the same issue? Or anyone have any idea why this could happen all of a sudden?
Thanks!
EDIT: after several attempts (by modifying our OAUTH code in some ways), it always failed. And we decided to create another brand new LinkedIn developer app, and it did work! This is really weird...
I'm working with the PayPal API and am trying to create an account as shown here.
The request is made to https://svcs.sandbox.paypal.com/AdaptiveAccounts/CreateAccount.
I'm able to send a valid request and get a response indicating success back but the redirect URL that's also returned as part of the response payload (which according to their docs is supposed to take the user to a PayPal sign up/registration page) is directing them to the following:
I've been unable to find anything on Stackoverflow or Google regarding this. Has anyone encountered this before? I'm assuming that even though it's a sandbox environment it should allow me to simulate the workflow somehow. I've tried with both the default sandbox credentials as well as for my own environment.
Looks like the issue was due to the IP address header in the request. The default configuration is:
-H "X-PAYPAL-DEVICE-IPADDRESS: 192.0.2.0"
While testing on localhost, I changed it to:
-H "X-PAYPAL-DEVICE-IPADDRESS: 127.0.0.1"
Also had to ensure that the email address didn't already have an account registered to it - in which case it would lead to a login page instead of the registration page (which is a little poorly designed in my opinion since you can't really test without making new accounts each time).
When I try to call Google to authenticate, I get an access_denied response.
I have the Google+ API enabled
This code was working yesterday and I do not see anything that would cause it to break now.
This code works in one environment (dev) but fails in another (test).
I updated our test environment to have the same code (copied from dev) and it fails there.
This seems to be server related, but I can't figure out why.
Google's configuration has all the appropriate response and redirect uris (I just changed the subdomain).
Is there anyway I can find out WHY access is denied?
One possible cause for getting a generic access denied error when interacting with Google is their block on "less secure apps": https://support.google.com/accounts/answer/6010255?hl=en
It generally returns an error that is assumed by most apps and sites as an incorrect password, even if your password is correct. If you are using different Google accounts between dev and test, and one is configured differently than the other, this might be a possible reason.
I'm trying to develop a desktop application to access an API exposed by Groundspeak for geocaching.com. The API requires the use of OAuth.
After finally figuring out why my message signature was being rejected (I had to double-encode my callback URL, after reading somewhere that double-encoding causes problems), I now receive the following error from Groundspeak when attempting to get a request token:
oauth_error_message=Error%20while%20reading%20message%20%27DotNetOpenAuth.OAuth.Messages.UnauthorizedTokenRequest%27%20parameter%20%27oauth_callback%27%20with%20value%20%27http%253A%252F%252Fwww.mysite.com%252F%27.
Not a very descriptive error message. What's the problem here? Groundspeak uses DotNetOpenAuth on its server. Seems like my callback URL might be causing some issue, but I don't have any idea what.
I should probably also say that I'm developing a desktop application, so the callback URL isn't really valid. It does point to a website I own, but that website has no idea about OAuth at all. If I omit the callback URL, I receive the error "Callback URL not present or not valid" or somesuch.
I don't know anything about Groundspeak but I'd guess that they require that you register your app's callback URL before using OAuth. At least Google and Microsoft do this with their OAuth APIs. Look for some kind of developer settings on Groundspeak.
This is definitely something that needs to be further defined in the future: OAuth for non-web applications. But there does seem to be a few possible solutions (not the cleanest) that you can try to get OAuth working within a desktop application. You can look into the articles below that have some working solutions (I have not tested this myself). It's based off of Google's workable solution for handling OAuth from installed desktop apps:
https://developers.google.com/accounts/docs/OAuthForInstalledApps
Link to possible workaround solutions:
http://blog.appharbor.com/2012/06/21/oauth-for-net-desktop-applications
Here's also a related article on SO for desktop app OAuth: OAuth for Desktop apps?
Hope this helps!