This has the benefit of being possible from the _second_ riot instance, which may not actually have the email of the user registering. With these parameters, the RTS can get the email and user ID itself.
(see https://github.com/matrix-org/riot-team-server/pull/15)
This was necessary because the team token may not be known when registering, but domain is. Storing the icon under the "common" directory is the chosen solution to this.
Now that the RTS contains config for teams, use GET /teams to get that information so that users will see be able to register as a team (but not yet auto-join rooms, be sent to welcome page or be tracked as a referral).
For compatibility with referral campaign flows, re-implement team registration such that the team is selected through providing an email with a known team domain. The support email is now only shown when an email that _looks_ like a UK/US university email address, but is not known.
Also: This fixes registration with a team: only the email localpart was being used to register.
When a registration is successful, the user will be joined to rooms specified in the config.json teamsConfig:
"teamsConfig" : {
"supportEmail": "support@riot.im",
"teams": [
{
"name" : "matrix",
"emailSuffix" : "matrix.org",
"rooms" : [
{
"id" : "#irc_matrix:matrix.org",
"autoJoin" : true
}
]
}
]
}
autoJoin can of course be set to false if the room should only be displayed on the (forthcoming) welcome page for each team, and not auto-joined.
* Implement simple team-based registration
Config required goes in the `teams` top-level property in config.json. This consists of an array of team objects:
```json
{
"name": "University of Bath",
"emailSuffix": "bath.ac.uk"
}
```
These can be selected on registration and require a user to have a certain email address in order to register as part of a team. This is for vector-im/riot-web#2940. The next step would be sending users with emails matching the emailSuffix of a team to the correct welcome page as in vector-im/riot-web#2430.
This will happen anyway when they follow email verification links.
make captchas poll for success so if they are completed elsewhere, electron moves on
Use the new register-specific request token endpoint (https://github.com/matrix-org/matrix-js-sdk/pull/147) and catch the error that it gives if the email is already in use. Also add initial values to the registration form so we can reload it after the error without all the values disappearing, and split out the guest username parameter which was previously called defaultUsername.
1) custom HS/IS urls are now persisted in HTML5 local storage. As a result, all the login components now distinguish between default HS/IS URLs and custom specified ones again. (
2) custom HS/IS urls are synchronised between the instances of ServerConfig found in the Login, Registration and Forgot Password screens.
3) username are persisted over changing homeserver (but not password, to stop accidentally leaking passwords to the wrong server)
4) correctly interpret a blank URL field as meaning the placeholder text
5) when toggling custom URLs on and off, remember what the custom values were, and use the default URLs if custom mode is not engaged
also, guest access now upholds custom HS/IS URLs found in local storage rather than being limited to the server config ()
also adds assorted comments and improved console debug and a few minor cosmetic changes to the login components.
this commit sponsored by VS27...
This is preferable to doing the way other QPs are passed (secret, etc) because
the link in the email wants to look like "#/room/<room_id_or_alias>" for guest
read-access (only bouncing you to /login if that room is not readable by guests).
This is hard to do in the current arch because we don't preserve QPs on /room
paths, and we do conditional executions depending on if it is a room ID or
alias. Rather than threading through the email in each section and creating
a fragile mess, just pass the *starting* set of query parameters through to
MatrixChat which can then do the Right Thing when the time comes.
