Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-01-05 07:23:42 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Speeeeeeling

Browse source 
Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
This commit is contained in:
Travis Ralston 2019-08-19 10:42:30 -06:00 committed by GitHub
parent 865d3da0f8
commit 9e073e9647
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
proposals/1957-integrations-discovery.md
View file

@ -100,7 +100,7 @@ user so they don't get left out.
#### Displaying integration managers
Clients simply open the `ui_url` (or equivalent) in an `iframe` or similar. In the current ecosystem,
integration managers would receive a `scalar_token` to idenitify the user - this is no longer the case
integration managers would receive a `scalar_token` to identify the user - this is no longer the case
and instead integration managers must seek other avenues for determining the user ID. Other proposals
cover how to do this in the context of the integrations API.
@ -159,7 +159,7 @@ Some things which may be desirable in the future are:
## Security considerations
When displaying integration managers, clients should not trust that the input is sanitary. Per the
proposal above, an intergration manager is only permitted to be served from HTTP(S) URIs. A given
proposal above, an integration manager is only permitted to be served from HTTP(S) URIs. A given
integration manager can still have malicious intent however, and clients should ensure any sandboxing
on the manager is appropriate such that it can communicate with the client, but cannot perform
unauthorized actions. Other URI schemes are just as dangerous and could potentially be allowed by