I'm trying to use the auth0-react package, which redirects the user to the provided domain + /authorize
<Auth0Provider
domain="mydomain/oauth2"
// redirects to mydomain/oauth2/authorize?...
clientId="myClientId"
redirectUri={"http://localhost:1557/send-params"}
/>
...
The problem is, the domain I'm trying to request uses the path /auth as opposed to /authorize, as stated in the Auth0 OAuth 2.0 spec. I'm wondering why the spec and the SDK direct to /authorize, and some providers, like Google, use /auth.
Also, if anyone has experience with the auth0-react package, is there a way to change the endpoint that is called from /authorize to /auth?
The correct library behaviour should be to look up endpoints using OpenID Connect Discovery, since there is nothing in standards to say what the endpoint relative URLs are.
Hopefully there is an Auth0 option to do this - I will take a look at the Auth0 repo later. Generally though I avoid vendor specific libraries for this type of reason.
OIDC Client is an example library that works with any standards based provider. But then SPAs are moving to more of a back end for front end pattern anyway - hence this library being archived.
POSTSCRIPT
I have a look and it seems that the above library depends on the auth0-spa-js library and its Auth0Client class which hard codes the path. You may be able to subclass this client to solve your problem.
Related
I am building my first ever Chrome browser extension and I am struggling to find the right solution for handling authentication. There is a requirement that the extension stay logged in as long as possible, to reduce the need for the user to log in often. This means we would need to use Refresh Tokens. I would very much like to handle all authentication on the background script but this is no longer persistent in MV3 nor does it have access to the DOM.
This being the case, I see these options:
use Auth0 React SDK on the content scripts - this means all my authentication logic will run in a somewhat less secure environment but the token will be handled by the library and I will be able to access it in all my content and popup scripts (if I need persistence across page refreshes, I would still need to use localStorage, I believe). But this means that the background script will not have access to the token and it will need one of the other scripts to retrieve it and send it through a message
implement the Authorization Code Flow with PKCE following the steps in this tutorial on the background script - this will mean that all my auth logic is running in a more secure environment but I don't have a way of storing the token, other than using chrome.storage. It's also a bit tricky to silently retrieve the token (or check if user is still logged in) from the background script (it can be done using an injected iframe and the web_message response type or with chrome.identitybut there are still issues with the redirect_uri which needs to be listed in the Allowed Origin config of the Auth0 app - so you can only easily do this on the pages of the extension).
I know that the recommended solution for an SPA is using the SDK but I would like to know if this is also the right solution for a browser extension. Based on this article on Token Storage, localStorage is dangerous especially due to third-party scripts. Seeing that the MV3 manifest has now removed the ability to execute remote code, is localStorage an acceptable way to store tokens?
I have implemented both options using the docs provided but I am unsure as to what is the best solution, given the changes introduced by MV3.
Thank you
I am beginner in MEAN stack.
When invoking unauthenticated REST API (no user log-in required), API end-points are exposed in the JS files. Looked through forums that, there is no way to prevent abusers using the API end-point directly or even creating their own web/app using those end-points. So my question is, are there any way to avoid exposing the end-points in the JS files?
On a similar note, are there any ways, not to use REST calls on front-end and still be able to serve those dynamic content/API output data in a MEAN stack? I use EJS.
There's no truly secure way to do this. You can render the page on the server instead, so the client only sees HTML (and some limited JS).
First, if you don't enable CORS, your AJAX calls are protected by the browser, i.e. only pages served from domain A can make AJAX calls to domain A.
Public API providers like Google Maps protect themselves by making you use an API key that they link to a Google account.
That key is still visible in the JS, but - if abused - can be easily disabled.
There's also pseudo-security through obfuscation, i.e. make it harder for an attacker to extract a common secret you are using the encrypt the API interaction.
Tools like http://javascript2img.com/ are far from perfect, but makes attackers spend a lot of time trying to figure out what your code does.
Often that is enough.
There are also various ways to download JS code on demand which can then check if the DOM it runs in is yours.
Is there a url pattern that will by default route traffic to a specific version using a custom domain and SSL on app engine, without specifying the routing in a disptach file? I.e. something like
https://themagic.mydomain.com
Where themagic may include dots, dashes - whatever it takes?
The docs specify various options, but none that are both SSL and mydomain.com, they are:
https://instance-dot-version-dot-module-dot-app-id.appspot.com
http://instance.version.module.app-id.my-custom-domain.com
Sends the request to the named module, version, and instance.
https://version-dot-module-dot-app-id.appspot.com
http://version.module.app-id.my-custom-domain.com
Sends the request to an available instance of the named module and version.
These address forms have a default routing behavior. Note that the default routing is overridden if there is a matching pattern in the dispatch file:
https://module-dot-app-id.appspot.com
http://module.app-id.my-custom-domain.com
Sends the request to an available instance of the default version of the named module.
https://version-dot-app-id.appspot.com
http://version.app-id.my-custom-domain.com
Sends the request to an available instance of the given version of the default module.
https://app-id.appspot.com
http://app-id.my-custom-domain.com
Sends the request to an available instance of the default version of the default module.
For several years I have been using the routing
https://version1.www.mydomain.com
This historically worked fine to route traffic to the version called version1 on the default modile, and continues to work. But I'm uncomfortable with it because a) it's not documented (as far as I can find) b) it's tricky to get the SSL setup. Specificall on the SSL, the only way (as far as I can tell) is to use a wildcard SSL cert (which is either pricey, or self signed). My attempts to use this URL with an SSL cert signed only for version1.www.mydomain.com resulted in the traffic being routed to the default version, presumably because of the specific 'custom domain' rules that one needs to add via appengine's web UI (cloud console) in order to add the SSL cert. So for now, a self signed wild-card cert is the only way I can make it work.
Through experimentation, it also seems that version-www.mydomain.com may be a valid routing to that version, but again, whether this can be setup with SSL is in doubt, and there's no docs on it.
If at all possible, please link to documentation.
Updated answer
It appears that while this is working as intended, it's not a case of soft routing, but rather subdomain -> version / module routing described elsewhere on the same docs page linked originally. There was an issue with the form of the subdomains shown in the docs at the time this comment exchange occurred, which should be fixed shortly to be more clearly readable.
https://module-dot-app-id.appspot.com
http://module.app-id.my-custom-domain.com
Should become:
http(s)://module-dot-appid.appspot.com
OR
http(s)://module.appid.appspot.com
OR
http(s)://module.custom-domain.com
Or an equivalent.
Original answer
The documentation you linked adequately describes the routing rules. What you've observed in terms of default-module routing is an example of the "Soft Routing" the docs describe. Explicit addressing of modules and versions will need to take the form the docs requires, else the request will go to the default module.
I've exposed a few APIs using go-endpoints. The APIs work fine, but what I'd like to do is restrict usage of the APIs to only a few referers. Since I'm not passing any authentication information, I do not need OAuth (actually, I really do not want to use OAuth as I expect anonymous users to utilize a front-end that uses this API... I just want that front-end and perhaps another one to use my API).
Apparently the way to do this is to make a Public API Key using the Google Developers Console (Project --> APIs and auth --> Credentials --> Create new Key).
I've changed my JavaScript to use this key, by passing it as a param: https://my-app-id.appspot.com/_ah/api/myService/v1/doSomething?key=key_from_developer_console
However, when I make the call, I get a 403 back with this error:
"Access Not Configured. The API () is not enabled for your project. Please use the Google Developers Console to update your configuration."
Well, initially I set the referer to my-app-id.appspot.com/*, which is only place I want my API to be used from. So I figured I'd remove it just to see, but I get the same issue.
There are some old posts here about having to enable Contacts API and Google + API. I tried that, and it didn't work either.
So what gives? There is virtually no documentation from Google on this Public API Key feature. This is really driving me up a wall...
I had this exact same problem yesterday. I decided to generate my own key and added in my own logic to check for the 'key' param from the request. I just added the self-generated key to my env_variables and it works. However, if you try to redeploy after taking this approach, you may still see the access configuration issues..at least I have still.
in the official trigger.io docs there seems to be no provision for custom http headers when it comes to the forge.file module. I need this so I can download files behind an http authentication scheme. This seems like an easy thing to add, if support is not already there.
any workarounds? any chance of a quick fix in the next update? I know I could use forge.request instead, but I'd like to keep a local copy (saveURL).
thanks
Unfortunately the file module just uses simple "download url" methods rather than a full HTTP request library, which makes it a fairly big task to add support for custom headers.
I've added a task to our backlog for this, but I don't have a timeframe for it being added.
Currently on iOS you can do basic auth by using urls in the form http://user:password#url.com in case that helps.
Maybe to avoid this you can configure your server differently, or have a proxy server in front that allows you to pass authentication details as get parameters?