Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

http error 400 bad request (or similar) after oidc unsucessful auth leads to unresponsive client #21

Open
raffis opened this issue Oct 11, 2017 · 11 comments
Assignees
Labels
Milestone

Comments

@raffis
Copy link
Contributor

raffis commented Oct 11, 2017

Something bad happened  { Error: listen EADDRINUSE 0.0.0.0:13006
    at Object.exports._errnoException (util.js:1050:11)
    at exports._exceptionWithHostPort (util.js:1073:20)
    at Server.setupListenHandle [as _listen2] (net.js:1263:14)
    at listenInCluster (net.js:1304:12)
    at doListen (net.js:1428:7)
    at _combinedTickCallback (internal/process/next_tick.js:83:11)
    at process._tickCallback (internal/process/next_tick.js:104:9)
  code: 'EADDRINUSE',
  errno: 'EADDRINUSE',
  syscall: 'listen',
  address: '0.0.0.0',
  port: 13006 }

balloon desktop version

0.0.30

Your client operating system

Windows 7

Filesystem (If known)

balloon server version (If known)

@raffis raffis self-assigned this Oct 11, 2017
@raffis raffis added the bug label Oct 25, 2017
@raffis
Copy link
Contributor Author

raffis commented Nov 15, 2017

openid/AppAuth-JS node_support/node_request_handler.ts server does start only in private context.

@raffis raffis added this to the 1.0.x milestone Dec 4, 2017
@raffis
Copy link
Contributor Author

raffis commented Dec 19, 2017

this happens after removing refreshToken and accessToken on the server during an active sync and sync will stuck forever.

Request ended with an error  400 { error: 'invalid_grant',
  error_description: 'no such refresh token' }
Making a request to  AuthorizationRequest {
  clientId: 'xxx',
  redirectUri: 'http://127.0.0.1:13006',
  scope: 'openid profile offline_access',
  responseType: 'code',
  extras: { prompt: 'consent', access_type: 'offline' },
  state: 'BEIQ8K0XrE' } https://oidc/auth?redirect_uri=http%3A%2F%2F127.0.0.1%3A13006&client_id=xxx&response_type=code&state=BEIQ8K0XrE&scope=openid%20profile%20offline_access&prompt=consent&access_type=offline
Request ended with an error  400 { error: 'invalid_grant',
  error_description: 'no such refresh token' }
Something bad happened  { Error: listen EADDRINUSE 0.0.0.0:13006
    at Object.exports._errnoException (util.js:1050:11)
    at exports._exceptionWithHostPort (util.js:1073:20)
    at Server.setupListenHandle [as _listen2] (net.js:1263:14)
    at listenInCluster (net.js:1304:12)
    at doListen (net.js:1428:7)
    at _combinedTickCallback (internal/process/next_tick.js:83:11)
    at process._tickCallback (internal/process/next_tick.js:104:9)
  code: 'EADDRINUSE',
  errno: 'EADDRINUSE',
  syscall: 'listen',
  address: '0.0.0.0',
  port: 13006 }
Request ended with an error  400 { error: 'invalid_grant',
  error_description: 'no such refresh token' }
Something bad happened  { Error: listen EADDRINUSE 0.0.0.0:13006
    at Object.exports._errnoException (util.js:1050:11)
    at exports._exceptionWithHostPort (util.js:1073:20)
    at Server.setupListenHandle [as _listen2] (net.js:1263:14)
    at listenInCluster (net.js:1304:12)
    at doListen (net.js:1428:7)
    at _combinedTickCallback (internal/process/next_tick.js:83:11)
    at process._tickCallback (internal/process/next_tick.js:104:9)
  code: 'EADDRINUSE',
  errno: 'EADDRINUSE',
  syscall: 'listen',
  address: '0.0.0.0',
  port: 13006 }
Handling Authorization Request  { state: 'BEIQ8K0XrE',
  code: 'xxx' } BEIQ8K0XrE xxx undefined
Checking to see if there is an authorization response to be delivered.

@raffis
Copy link
Contributor Author

raffis commented Dec 19, 2017

See #68

@pixtron pixtron self-assigned this Oct 31, 2018
@pixtron
Copy link
Member

pixtron commented Nov 1, 2018

The original error EADDRINUSE can be reproduced with these steps:

1.) Revoke all grants given to app on IDP A
2.) link account
3.) choose IDP A from list of IDP's
4.) Browser window opens providerUrl, asking for credentials
5.) close browser without logging in
6.) choose IDP A from list of IDP's

As step 3.) already started the notifier server on given port, step 6.) can't open another server on the same port.

The problem would also occur if some other process is already listening to the configured port.

Fixes:
1.) Only start notifier once?
2.) Try to catch the error? (although it seems the error is swallowed and just logged by openid/appauth)
3.) Use random ports, if another process is already listening to the given port?

@raffis
Copy link
Contributor Author

raffis commented Nov 1, 2018

Fixes:
1.) Only start notifier once?

As far as I can remember the listener gets started internally by the oidc lib.

2.) Try to catch the error? (although it seems the error is swallowed and just logged by openid/appauth)

I tried that once with no success, maybe needs another shot.

3.) Use random ports, if another process is already listening to the given port?

Doesn't work since you need to specify the whole uri in the redirect_uri registration for the oidc client.

@pixtron
Copy link
Member

pixtron commented Nov 13, 2018

Notifier gets started internally, and can't be shut down (openid/AppAuth-JS/issues/89).
The error can only be caught with process.on('UncaughtException', err => {})(openid/AppAuth-JS/issues/95). Fixed port seems to be a restriction of certain idp's.

@pixtron
Copy link
Member

pixtron commented Nov 13, 2018

The issue with the 400 errors in 21#issuecomment-352744114 should be fixed by #137

@raffis
Copy link
Contributor Author

raffis commented Nov 29, 2018

Workaround: Maybe restart app if unexpected error encountered.

@pixtron
Copy link
Member

pixtron commented Dec 5, 2019

A restart is not practicable, as another process might be listening on the port. In this case we would hafe an "Infinite loop" of restarts.

@raffis raffis added this to the 1.3.x milestone Dec 5, 2019
@pixtron
Copy link
Member

pixtron commented Feb 18, 2020

If another process is listening to the specified port, it might help to allow configuration of multiple redirectUris with different ports. the client could then retry with another redirectUri/port.

@raffis raffis modified the milestones: 1.3.x, 1.4.x, 2.0.x Mar 5, 2020
@raffis
Copy link
Contributor Author

raffis commented Mar 5, 2020

This can be fixed with the server v3 which comes with hydra which has support for RFC8252 section-7.3 Loopback Interface Redirection, see pr#400 to fosite

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants