Return 302 on WebFinger when the user has moved

[cmrd-senya]

RFC 7033 allows to redirect client to another resource.

When user has migrated it makes sense to return 302 when a WF request is made to the old resource and old host.

In order to do that we need to modify webfinger controller. Since we just rely on request to a gem user with fetch_person_for_webfinger callback I think we need to return another object instead of WebFinger entity in case of account move and just test it in the controller. If the callback returned the "moved object", we reply with 302.

Opinions?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[SuperTux88]

I'm unsure, I don't know if it's useful to return a 302, or if it's better to still allow to fetch the old person to get the old key. Old relayables are still signed with the old key, so I don't know if we want to resign them all or if we want to add a possibility to get the old key.

Also, the current WebFinger implementation would follow a 302, but would then fail, because the subject of the response after the redirect wouldn't match the requested diaspora ID.

So it's maybe better to add something to the WebFinger or hCard response that points to the new user, so we can still fetch the old user/key and also have a way to find the new user. But I agree that there should be something that points from the old user to the new user after the migration. What do you think?

[cmrd-senya]

Maybe it's possible to return 302 code and also a webfinger body in the same response for the old account? I guess it is not restricted by the specification. So we can still fetch the old profile this way and we get both moved response code 302 and new profile location. Thus pod can fetch both old and new profiles at once, and AccountMigration object as well.

[SuperTux88]

No, this feels really hacky. Our implementations currently follows automatically a number of redirects. We would need to intercept that, check if the response body contains a valid WebFinger response, and if not, continue follow the redirect. This would even be harder when somebody uses a library to request/parse the WebFinger (for example webfinger or goldfinger).

Also our implementation checks if the subject matches the requested diaspora ID (which is also mentioned in our documentation). While this is allowed in the RFC 7033, it's still dangerous to just follow a redirect blindly. Both accounts need to agree to the migration, so we also need to validate the target.

To me it looks much clearer when we just add a link relation to the WebFinger response which points to where the account_migration message can be fetched (from the target server). That way we don't need a 302-with-body hack, and we also can validate the signature of the source and the target (because we have the complete account_migration message then). Since our generic fetching routes only specifies fetching of entities with GUID, we need to specify a special case here, for example /fetch/account_migration/:new_username. When we want to support merging multiple accounts into one target, we also need to add the source diaspora ID somehow. Rails does magic when the path contains . (because it uses the last . for the format), so maybe something like this? /fetch/account_migration/:new_username?source=:old_diaspora_id (details about this still need to be discussed)