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

Allow email registration when no IS #10571

Closed
dbkr opened this issue Aug 15, 2019 · 8 comments · Fixed by matrix-org/matrix-react-sdk#3318

Comments

@dbkr
Copy link
Member

commented Aug 15, 2019

Split from #10552

@dbkr dbkr added this to In Progress in Workflow Aug 15, 2019
@dbkr dbkr self-assigned this Aug 15, 2019
@anoadragon453

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

@dbkr What do you think about having /capabilities show you basic information if you're not authed, and auth-specific information if you are authed?

More work, but might be better down the line, plus it'll work for anything that requires knowing whether the homeserver handles email itself, which may be more than endpoints using UIAA.

@dbkr

This comment has been minimized.

Copy link
Member Author

commented Aug 15, 2019

Yeah, I think that seems fairly reasonable. Only downside I can think of is that it's not necessarily obvious that authing will give you a different result, but it's probably not a problem.

@anoadragon453

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

True. I'm also trying to think about how we will represent this in the spec, as currently we only have Requires Auth: <bool>.

Perhaps we don't require authentication on GET /capabilities, but do require it on POST /capabilities? Does anything currently require auth on /capabilities?

Spec for ref: https://matrix.org/docs/spec/client_server/unstable#get-matrix-client-r0-capabilities

@dbkr

This comment has been minimized.

Copy link
Member Author

commented Aug 16, 2019

ah yes, although we shouldn't make decisions about our API based on what can be represented in the doc. :p If we were going to split them I'd say make 2 endpoints with different names, but personally I think I'd go for requires auth: no, then just add a freetext comment for now saying if you auth, maybe you'll get more stuff.

@anoadragon453

This comment has been minimized.

Copy link
Member

commented Aug 16, 2019

What do you think about:

  • /capabilities/server - public capabilities of the server, no auth
  • /capabilities/user - user auth required and scoped capabilities

where /capabilities just returns what /capabilities/user returns for backwards compatibility?

@dbkr

This comment has been minimized.

Copy link
Member Author

commented Aug 16, 2019

where /capabilities just returns what /capabilities/user returns for backwards compatibility?

other way around?

otherwise, yeah, I could get on board with that

@anoadragon453

This comment has been minimized.

Copy link
Member

commented Aug 16, 2019

/capabilities is currently authed, and /capabilities/user would be the authed one.

Ok, I'll write the MSC for it.

@dbkr

This comment has been minimized.

Copy link
Member Author

commented Aug 16, 2019

oh, right, yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Workflow
In Test
2 participants
You can’t perform that action at this time.