feathers
feathers copied to clipboard
Easier local debugging for OAuth2 providers
The problem
When doing local tests in order to try/test external OAuth2 service providers, it gets really hard to work with localhost on NODE_ENV that are not 'development' or 'test'.
It would be very simple and a big deal for local testing to instead of forcing http/https and port number based on the environment name, to be able to set it in the config file.
The code:
https://github.com/feathersjs/feathers/blob/3215714766f047cc9526f260796467b3c52f8d15/packages/authentication-oauth/src/index.ts#L34-L42
What could be done:
Replace: let protocol = 'https';
With: let protocol = get('protocol') || 'https';
And remove:
// Development environments commonly run on HTTP with an extended port
if (app.get('env') === 'development') {
protocol = 'http';
if (String(port) !== '80') {
host += ':' + port;
}
}
You should already be able to overwrite host and protocol in the oauth configuration settings defaults:
{
"authentication": {
"oauth": {
"redirect": "/frontend",
"defaults": {
"host": "localhost",
"protocol": "https"
},
"google": {
"key": "...",
"secret": "...",
"custom_params": { "access_type": "offline" }
},
"twitter": {
"key": "...",
"secret": "..."
}
}
}
}
I tried that but is not just the protocol, is also that is not using the same port. For instance I run a server locally that has a different config (it will connect to a remote database) so is not my development environment but my "local-remote" environment.
That will create an OAuth callback link like this: http://localhost/oauth/google/authenticate instead of http://localhost:3000/oauth/google/authenticate.
Maybe, to avoid potencial security issues (ensuring https, etc.), the appropriate solution would be to change this line:
https://github.com/feathersjs/feathers/blob/3215714766f047cc9526f260796467b3c52f8d15/packages/authentication-oauth/src/index.ts#L37
From: if (app.get('env') === 'development') { to if (app.get('env').indexOf('development') !== -1) {
That way any development-something environments could behave that way (I would change mine to development-remote in that case.
I believe this is addressed now in the latest version of the oAuth plugin.