My WebID isn't working on foreign site

[kjetilk]

When trying to log into a remote site to a non-public document that my WebID https://solid.kjernsmo.net/profile/card#me has been given access to, I end up getting redirected to the remote site's login page.

There has been some debug activity on gitter, but I figured I might as well make an issue on it, and attach a HAR file with a record of a session.

[dmitrizagidulin]

What’s the error, though? Getting redirected to the remote site for login is the expected behavior.

[kjetilk]

Huh? But surely, I shouldn't need an account on the remote site to access the documents that my own identity has been authorized to access?

[dmitrizagidulin]

From conversation on Gitter, it sounds like the steps were:

1. Access a write-protected resource on inrupt.net, get a 401 Unauthorized response, get redirected to Select Provider screen.
2. Enter an external Web ID (hosted on solid.kjernsmo.net), get redirected to kjernsmo.net/authorize endpoint.
3. Log in at solid.kjernsmo.net via username & password.

Expected: to be redirected back to the /shared/ protected resource on inrupt.net

Actual: got redirected to inrupt.net/login instead.

From the HAR log above, note that during the initial redirect to kjernsmo.net/authorize, the redirect_uri=https://inrupt.net/api/oidc/rp/https%3A%2F%2Fsolid.kjernsmo.net param is present (inside the request JWT), as expected.

And after login via password, the user is redirected to https://inrupt.net/api/oidc/rp/https%3A%2F%2Fsolid.kjernsmo.net, with the code and state params, as expected. So far so good.

So it sounds like the main issue is that the redirectUrl mechanism, after the callback request, is not working (and resorting to the default /login value).

This was recently fixed in PR #648, so this is either a regression, or maybe inrupt.net running an older solid-server version?

[dmitrizagidulin]

Ok, so it sounds like inrupt.net is running version 4.0.14, which is after pr #648.

[dmitrizagidulin]

For reference, this is from inrupt.net's server console log, which may be related to this redirect behavior:

Jun 28 08:39:44 ip-10-1-0-245 solid[8478]: Thu, 28 Jun 2018 08:39:44 GMT solid:authentication Logging in via username + password
Jun 28 08:39:44 ip-10-1-0-245 solid[8478]: Thu, 28 Jun 2018 08:39:44 GMT solid:authentication Attempting to login user: kjetil.inrupt.net/profile/card#me
Jun 28 08:40:12 ip-10-1-0-245 solid[8478]: Thu, 28 Jun 2018 08:40:12 GMT solid:authentication Discovering provider for uri: https://solid.kjernsmo.net/profile/card#me
Jun 28 08:40:13 ip-10-1-0-245 solid[8478]: Thu, 28 Jun 2018 08:40:13 GMT solid:authentication Building /authorize url for provider: https://solid.kjernsmo.net
Jun 28 08:40:13 ip-10-1-0-245 solid[8478]: Thu, 28 Jun 2018 08:40:13 GMT solid:authentication Client fetched for issuer https://solid.kjernsmo.net
Jun 28 08:40:13 ip-10-1-0-245 solid[8478]: Thu, 28 Jun 2018 08:40:13 GMT solid:authentication Client fetched for issuer https://solid.kjernsmo.net
Jun 28 08:40:14 ip-10-1-0-245 solid[8478]: Error in AuthCallbackRequest: TypeError: Cannot read property 'payload' of undefined
Jun 28 08:40:14 ip-10-1-0-245 solid[8478]: at AuthCallbackRequest.initSessionUserAuth (/usr/lib/node_modules/solid-server/node_modules/oidc-auth-manager/src/handlers/auth-callback-request.js:120:34)
Jun 28 08:40:14 ip-10-1-0-245 solid[8478]: at Promise.resolve.then.then.then.then.session (/usr/lib/node_modules/solid-server/node_modules/oidc-auth-manager/src/handlers/auth-callback-request.js:90:32)
Jun 28 08:40:14 ip-10-1-0-245 solid[8478]: at process._tickCallback (internal/process/next_tick.js:68:7)

[dmitrizagidulin]

Ok, found the cause of the Cannot read property 'payload' of undefined error above, fix coming shortly (to the oidc-auth-manager lib).

Not sure if there's a separate cause for the redirection error, will re-test after the fix.

[dmitrizagidulin]

Yep, there it is. in oidc-auth-manager/src/handlers/auth-callback-request:

 return AuthCallbackRequest.handle(request)
 .catch(error => {
 request.debug('Error in AuthCallbackRequest:', error)
 res.redirect('/login')
 })

There's the redirect to /login in case of error.

[dmitrizagidulin]

(This is fixed in develop branch)