Apparently there are a lot of people having this problem, but none of the scenarios seem to be exactly what I'm experiencing. I'm using Azure AD B2C with HTTPS. I can consistently create the problem, but am at a loss to know how to fix it.
Recreating the problem:
Make sure to be logged out.
Go directly to a link in the site. This will bring up the login screen. After successful login, the user should be taken to the page in question.
Hit the "Back" button. This brings up the error, and the user will be at https://domain/MicrosoftIdentity/Account/Error.
I've tried every combination/permutation of cookie policies I can think of, but to no avail.
If I can't solve the problem, perhaps someone could tell me how to redirect https://domain/MicrosoftIdentity/Account/Error to https://domain/MicrosoftIdentity/Account/SignOut, thereby simply forcing a loggout. I'd be satisfied with that.
What this really is:
From an authentication/application's perspective this behavior is correct. Let me clarify. I bet the following is something almost every internet user has experienced:
You submit a form, click on the back button and this alert pops up, asking you to 'resubmit the form'?
When you clicked back in the browser it simply executes the exact same request that you did earlier. Not a big deal in HTTP-GET requests, but kind of a pita in POST-requests because it can potentially cause duplicate data or worse. Or in this case, you run into security measures preventing the (ab)use of one-time tickets.
Although the behavior is correct, I understand that your client's perception is, that the app must simply be broken..
The solution, or preventive measure:
To be clear, I haven't actually tried this and this is more of a 'could-possibly-work' answer in the case of AzureAD B2C.
Nevertheless, I think you might be able to circumvent this perceived problem through:
Implementing a POST-redirect-GET pattern inside your application so that you point the redirect URI of the B2C tenant to an endpoint inside your application and when the request comes in, simply redirect the request to a GET method.
Hopefully this helps, but in case you want a more definitive answer try searching Google for the pattern or maybe someone else here knows about a working solution and wants to contribute to this post in the comment section or provide an answer. Either way, good luck!
Related
Well like the title suggest I am having a strange problem with the api oauth2.0 I wanted to play with the API in the sandbox before deploying live like any sane person to start pulling call recordings. Well when I was setting up the Oauth and it was a pain but I got to work, or at least I thought until it asked me to add an address for the sandbox profile after accepting all the other steps in order to go any father. Every time I tried to add the address from the zapier login window it kept telling me it failed to try again later. I thought no big deal I will just add it from the user profile and well what do you know that didn't work either. I than made a new extension with a new number and email to see if it was just the account that was messed up, or if the dev account couldn't use the api for whatever reason but again no dice same problems all the way down. I even tried using three different browser to see if anything would change but no dice (not like that really matters everything is chrome based these days). I am wondering if anyone else has had this problem, did I miss something really simple that I am clearly over looking since I am running on 4 hours of sleep for the last two days.
If anyone could help I would appreciate it, love a very tired programmer.
In case anyone runs into the same problems, make sure when making a POST request to ring central you put the paramotors in the body of the request.
If I'm building a simple page to which one person (or a small number of people) will have admin access, how do I (ideally language-agnostically, but in Ruby if relevant) conceal the log-in link from most users, but reveal it to those who should have access?
I feel like this is something people must do all the time, and the answer is presumably all over Google, but I'm not quite sure what question I'm asking. I don't know what info I'd have to condition on (IP? What if admins want to log in from a different Wifi network?).
Is the normal approach to just not have a link, and use cURL or similar tools to log in? (which seems unwieldy)
Ah, I just realised at least one way of doing this is to have a page that I need to direct link to as the login page, so no-one sees a login link they can't use.
Feels obvious in retrospect :\
Today, out of the blue on the google page, a window popped up asking me for my username and password. It didn't say what it was for, just googleads.g.doubleclick.net. It then happened on my phone which is linked to the same account. I was wondering if anyone else has had this issue and if anyone could help me. I am really worried. Thanks.
Others have seen it. I did, when I opened Google Chrome. I was just on the new tab page, not even an actual website! Many people seem to have encountered this in the past 24 hours:
https://security.stackexchange.com/questions/127667/what-should-i-do-about-gmail-ad-asking-me-for-password
https://superuser.com/questions/1092011/firefox-googleads-g-doubleclick-net-basic-authentication-prompt
https://nz.answers.yahoo.com/question/index?qid=20160621202130AAxY0F2
https://steamcommunity.com/discussions/forum/11/358415738179518104/
https://productforums.google.com/forum/#!msg/chrome/Rt3zSPiSyHk/zdB52fBqAQAJ
http://forums.windowscentral.com/windows-10/429066-edge-wants-me-login-googleads-g-doubleclick-net.html
https://techreport.com/forums/viewtopic.php?f=1&t=118101
https://forums-windowscentral-com.blogspot.com/2016/06/edge-wants-me-to-login-to.html
The best response I've found is over on the security stack exchange:
https://security.stackexchange.com/a/127668/43188
To summarize, yesterday, googleads.g.doubleclick.net (a Google domain that serves ads) either was briefly compromised by an attacker seeking people's passwords, or a Google engineer messed up and it's a result of a mistake in their servers.
The answer on the security stack exchange suggests changing your password, even if you didn't fill it in the popup. The suggest this because, if it's an attack, and the attacker is able to create the popup, they could have added malicious code you didn't see.
Also, though in principle I'm not a fan of ad blocking, I've recently realized it's probably necessary these days for security. This incident only demonstrates this. I recommend uBlock Origin, but Adblock Plus is also popular.
The context is a desktop app using the client-side OAuth flow for authentication.
When I first built this app nearly a year ago, Facebook's documentation said to use the following URL to generate the login/authorization dialog:
https://graph.facebook.com/oauth/authorize?client_id=XXXXXXXX&redirect_uri=YYYYYYY
This is working right now. However, I've reviewed the newly updated Authentication Guide and now see that Facebook is saying to use:
https://www.facebook.com/dialog/oauth?client_id=XXXXXXXX&redirect_uri=YYYYYYY
Does anyone know what the difference is between them, and more importantly do I need to change it? Like I said, it is working now, but I'm a little concerned about something changing when the 10/01/2011 deadline comes around.
My second question is: Does anyone know what enabling the "OAuth Migration" setting in the Apps -> AppName -> Advanced page does?
The URLs redirect to each other. But still, please make the change to the new URL. Whenever the docs change urls and the semantics are the same, you should update so as to avoid unnecessary breaking changes. Even more so with desktop apps.
Second answer: That will issue you different access tokens for now.
Is there a trick to logging in to Apple Developer Connection? For the past two weeks, out of about 100 tries, I've been able to log in three times. Every other time, after a successful entry of my username and password, it takes me back to the login screen.
This happens to me on both my Macs, on Safari and Firefox, so I'm not hopeful of a solution. But I have a hard time believing that the situation is really this bad...
I am having the same problem, I have narrowed down to a problem with my ISP. Of course they will not acknowledge it, but the problem only arises when I attempt a login from home. I think they are probably using a caching proxy and something in the scheme used by apple to login->access the content makes the proxy believe it's only visiting content that is still valid. I am going slightly mad because of this.
This question and the related discussion clued me in to how to fix my problem with the same symptoms on developer.apple.com. In my case, I have multiple "teams," so after entering in my Apple ID, it takes me to a team selection page. After selecting a team, I'd just be redirected back to the login/Apple ID page.
Turns out, the login is done over HTTPS, while the team selection (and probably the bulk of other activities on developer.apple.com) are over HTTP. Our firewall load balances over a couple of Internet connections, and the HTTPS traffic was passing over a different interface than the HTTP. Evidently, this was confusing Apple's authentication mechanism. It also explains why I was occasionally able to get through -- sometimes all traffic would end up on the same interface.
Ultimately, my solution was to add a rule to the firewall to send all 17.0.0.0/8 traffic (Apple's legacy class A network) over the same interface.
Hopefully this helps someone else with a frustratingly endless login loop.