cqrenet/mxids
3
0
Fork 0
Code Pull Requests 10 Actions Releases Activity

Rename config file, parameters, application name, package.

Browse Source
This commit is contained in:
Anatoly Sablin
2019-07-11 22:26:20 +03:00
parent c3262a9f25
commit e6fec9199d
41 changed files with 263 additions and 263 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/threepids/session/session-views.md
View File

@@ -27,12 +27,12 @@ Two configuration keys are available that accept paths to HTML templates:
- `failure`
### Serving static assets
mxisd will not serve any static asset (images, JS, CSS, etc.). If such are needed, you will need to serve them using the
reverse proxy sitting in front of mxisd using a path outside of the `/_matrix/identity/` namespace. We advise using
ma1sd will not serve any static asset (images, JS, CSS, etc.). If such are needed, you will need to serve them using the
reverse proxy sitting in front of ma1sd using a path outside of the `/_matrix/identity/` namespace. We advise using
the base path `/static/` for such use cases, allowing to remain under the same hostname/origin.
You can also serve such assets using absolute URL, possibly under other domains, but be aware of Cross-Origin restrictions
in browsers which are out of scope of mxisd.
in browsers which are out of scope of ma1sd.
## Placeholders
### Success

10
docs/threepids/session/session.md
View File

@@ -30,11 +30,11 @@ by a 3PID, allowing it to be resolved to a Matrix ID.
## Restrictions
### Bindings
mxisd does not store bindings directly. While a user can see its email, phone number or any other 3PID in its
ma1sd does not store bindings directly. While a user can see its email, phone number or any other 3PID in its
settings/profile, it does **NOT** mean it is published/saved anywhere or can be used to invite/search the user.
Identity stores are the ones holding such data, irrelevant if a user added a 3PID to their profile. When queried for
bindings, mxisd will query Identity stores which are responsible to store this kind of information.
bindings, ma1sd will query Identity stores which are responsible to store this kind of information.
Therefore, by default, any 3PID added to a user profile which is NOT within a configured and enabled Identity backend
will simply not be usable for search or invites, **even on the same Homeserver!**
@@ -60,7 +60,7 @@ Example: a user from Homeserver `example.org` adds an email `john@gmail.com`.
If a federated lookup was performed, Identity servers would try to find the 3PID bind at the `gmail.com` server, and
not `example.org`.
As mxisd is built for self-hosted use cases, mainly for orgs/corps, this is usually not a problem for emails.
As ma1sd is built for self-hosted use cases, mainly for orgs/corps, this is usually not a problem for emails.
Sadly, there is currently no mechanism to make this work for phone numbers.
## Notifications
@@ -68,7 +68,7 @@ Sadly, there is currently no mechanism to make this work for phone numbers.
Identity server that received the request. This is usually done by means of a URL to visit for email or a short number
received by SMS for phone numbers.
mxisd use two components for this:
ma1sd use two components for this:
- Generator which produces the message to be sent with the necessary information the user needs to validate their session.
- Connector which actually send the notification (e.g. SMTP for email).
@@ -134,7 +134,7 @@ on how to configure/customize/brand those pages to your liking.
This configuration would disable 3PID sessions altogether, preventing users from validating emails and/or phone numbers
and any subsequent actions that requires them, like adding them to their profiles.
This would be used if mxisd is also performing authentication for the Homeserver, typically with synapse and the
This would be used if ma1sd is also performing authentication for the Homeserver, typically with synapse and the
[REST password provider](https://github.com/ma1uta/matrix-synapse-rest-password-provider), where 3PID mappings would be
auto-populated.