OAuth2 redirect to https://...extensions.allizom.org seems to fail

Add-ons Development
1

Hi, I’m using OAuth2 to authenticate with some API in my Firefox Extension and everything worked fine until suddenly the extension (i.e., authentication) stopped working. I can login fine in the interactive login page of the API provider, and as far as I can tell the redirect_uri is called, but in my extension the promise of the Authentication flow is never fulfilled. If I paste the redirec_uri into the address bar, it results in a 404. Also, I can’t ping allizom.org or extensions.allizom.org. Any chance the service is offline?

Thank you for your help!
Cheers

1 Like
2

The target of the URI doesn’t have to be reachable for the flow to work. Does the OAuth flow you’re using set the code or token as an URL param? That’s what the flow is expecting.

3

Yes,it does. As far as I can tell, the redirect URL that is called is well-formed. Also, the exact extension used to work until some time ago, that’s why I was wondering if some server might not be reachable.

4

It doesn’t work for me.
@highsenberg did you solve the problem?
Even though it works in Chrome

5

@coddeys & @highsenberg Did you manage to fix this issue ? I’ma facing the exact same problem with my addon.
Thanks.

6

I have the same issue. I need a fixed redirect_uri for my client configuration at an authority server. I have managed to get this fixed redirect_uri by identity.getRedirectURL() (derived from the add-on’s ID) (as described here https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/identity)

e.g.
https://.extensions.allizom.org/

This URL is not reachable and it seems that only identity.launchWebAuthFlow knows how to interpret it.

However, I cannot use launchWebAuthFlow because I don’t want WebAuthFlow… I want SignInRedirect (~using other js libraries e.g. oidc-client, okta, …). The OAuth flow doesn’t continue its dance with this https://…extensions.allizom.org as a redirect_uri.

I could work around it by using webRequest.onBeforeRequest to observe any GET to this url. But I find it a little hacky and don’t feel like this is the right way to use identity.getRedirectURL() as intended by the Firefox team.

What is the intended use of identity.getRedirectURL()?
Thanks in advance!

1 Like
7

getRedirectURL is intended to be used in tandem with the webAuthFlow only - you have to pass in the full URL with all params to launchWebAuthFlow and many sites require you to give it the redirect_url in the URL params, as such it is not unsurprising that dealing with it with a custom flow (via webRequest or similar) is challenging.

1 Like
8

Can you confirm that the url returned by getRedirectURL is not reachable in an extension and that this is intended behavior?

If confirmed, this seems to be different than in Chrome.
If not confirmed, what needs to be done to make this url reachable?

1 Like
9

Super thanks @freaktechnik for your quick reply.
So the getRedirectURL is actually not reachable? I could imagine that launchWebAuthFlow can do anything with any arbitrary unreachable URL as it is executed in the context of the whole browser.
However, in a context of a web extension, if a redirect_uri is not reachable, then how can an extension handle post sign-in steps (namely storing tokens, etc.)? Did I miss something?

10

afaik the URL is not intended to work, though last time I checked it was reachable, it just didn’t open a valid TLS tunnel…

The intent is that you use launchWebauthFlow, but if you want to avoid that you should be able to read the URL with either the tabs or webNavigation APIs. And if all else fails, webRequest will for sure let you read the Location header your OAuth provider sends.

I’ve never built my own flow handler in WebExtensions, and if I did I’d probably not use the redirect URL provided by Firefox.

1 Like
11

Thanks. That explains what we encountered. It means we can use whatever redirect url. I still think is is different than how chrome works.