You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// this should be in our DB & we couldn't find it, so fail
if(supportedHandle){
thrownewInvalidRequestError('Unable to resolve handle')
}
Removing this allows the handle to be changed and everything seems to work perfectly fine.
The question is what is the reason for this restriction?
For *.example.com it makes sense because you can change the handle normally that way and those hostnames are automatically managed by pds, but it does not seem possible to create a user with handle @example.com without hacking the code.
Also, this prevents using *.*.example.com as handles, even though the automatic handles can only be on one subdomain level.
It is only needed for *.example.com to prevent making an unnecessary HTTP request to itself when it already knows it's not in db. Cause there's no reason an admin would put verification manually.
Suppose PDS hostname is example.com, you are @user.example.com and you want to change handle to @example.com
This code assumes @example.com must be in the database and prevents verification by DNS or HTTP with "Unable to resolve handle" error.
atproto/packages/pds/src/api/com/atproto/identity/resolveHandle.ts
Lines 26 to 32 in 27ff43b
Removing this allows the handle to be changed and everything seems to work perfectly fine.
The question is what is the reason for this restriction?
For *.example.com it makes sense because you can change the handle normally that way and those hostnames are automatically managed by pds, but it does not seem possible to create a user with handle @example.com without hacking the code.
Also, this prevents using *.*.example.com as handles, even though the automatic handles can only be on one subdomain level.
It is only needed for *.example.com to prevent making an unnecessary HTTP request to itself when it already knows it's not in db. Cause there's no reason an admin would put verification manually.
So I think it should be changed to this
The text was updated successfully, but these errors were encountered: