When running in open mode invites can be freely generated by accessing
/create-invite. This displays an HTML page which creates and displays an
invite to the user.
This commit adds an additional way of creating invites in open mode. A
POST request can be sent to the same /create-invite endpoint with the
Accept header set to application/json. This returns a JSON response
which contains an invite url.
The purpose of this change is to make automatic invite generation easier
in SSB clients.
Previously notices could only be displayed as HTML. This commit makes it
possible to request a list of notices as JSON. This can be used to
programmatically display a description of a room server in SSB clients.
The behaviour is governed by a query parameter. To list notices as JSON
set a query parameter "encoding" to "JSON" when listing notices (for
example https://example.com/notice/list?encoding=json). This parameter
was chosen instead of using the "Accept" header as similar behaviour is
already exhibited by other endpoints (namely the invite mechanism).
Reading the template of the invites page it was the intention of the
author to display the aliases instead of user refs if they are
available. The code loading the invites wasn't properly loading the
aliases of the useres who created them though always leading to this
data not being populated. This fix populates the aliases when listing
invites.
Additionally turned the invite author field into a link. This requires
some extra styling.
Fixes#245.
* fix rendering non-members on the dashboard
fixes#236
* remove alias or feedref code from template
doing this in the template was hard to read and inefficient.
also: rename OnlineMembers to OnlineUsers since it is a misnomer.
There are other connected peers in a room in certain privacy modes.
also update AuthFallback database
* re-write fallback auth to use alias or ssbid
* replace Create() with SetPassword() which does an upsert
* Add reset tokens to sqlite
* add test for SetPassword with reset token
* add tests for privacy mode settings
* test privacy mode settings for member role
* test default language settings
* test denied keys interface for each role
* test adding new member interface depending on role
* test member details depending on role
* test invite button is disabled pending on user role
* disable ui if user is unelevated
* disable revoke button if unelevated and not own invite
* improve styling of disabled elements
* remove revoke if alias not made my current user
to make sure the list of languages is sorted, we now use a slice of
TagTranslation{Tag: string, Translation: string} structs, sorted
by `TagTranslation.Tag`.
while working on the /set-language route, i noticed that i was getting a
csrf error for all /admin views when setting the language, while it
worked well on non-admin routes.
the issue, it turned out, was that we needed to configure gorilla's csrf
feature to set all cookies on the same route. when unconfigured, the
set cookies will only be set for the path they are being set at.
see more in the gorilla.csrf documentation (in particular the csrf.Path
option): https://pkg.go.dev/github.com/gorilla/csrf?utm_source=godoc#Path
boreq
decentral1se
decentral1se
Benjamin Steinwender
Andre Staltz
Henry
Tim Nordenfur
Henry
cblgh
User Cryptix