WIP: act as a Matrix OIDC auth provider #810
Labels
No labels
Bug
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status/Blocked
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
To-Merge
Wont fix
old/ci/cd
old/rust
No project
No assignees
6 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!810
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "lafleur/continuwuity:as-oidc-provider"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This MR proposes to implement acting as an OIDC authentication provider following the expectations of
The OIDC token flow implies an OAuth transaction implemented with the
oxide-authcrate. An enhancement could be to add html templates support for the login and consentment pages (and the future account registration/management pages).The token flow was tested against areweoidcyet.com, and passes all the steps. Unfortunately, I was unable to use that flow with any app supporting new-style authentication.
MSC4254 (token revocation) should be straightforward to implement, I'll do it soon.
These MSCs form MSC3861, that recently landed in the spec - see their blog.
Thank you for the PR! I'd like to get #801 merged, then we can work on a basic HTML login page, then we can get login working with Element Web. & Element X as our test targets. We'll also need to add the database tables for dynamic client registration - as it's entirely new tables, that shouldn't cause any database compatibility issues with other conduits, but we'll need to pay attention if any modifications are required elsewhere to the database in the process.
I also want to see if we can move the routing stuff to ruwuma, although that's a lower-priority change.
All that said, this is an excellent start, thank you again! I'm quite happy with using
oxide-authhere to avoid maintaining that code ourselves, and it looks well-maintained from a quick glance.Great ! I noticed you added the askama crate in #801, I should be able to update this MR once you merge it to use its templating system in the current login page - and perhaps the css you added, if it's ment to be site-wide.
Currently I implemented the clients db as a volatile struct using oxide-auth's tooling. This means it's reset at server shutdown. I thought it was fine because I thought clients had to register on each connection anyway, but now I understand that they expect their registration to stay valid across server restart. So yes, I guess we have to add new tables.
BTW, I believe the implementation of msc2965 implies that user registration takes place at a new web endpoint,
/_matrix/static/client/register(which is a bit confusing for an user registration endpoint if you ask me). So I'd like to implement that endpoint too, even if I couldn't find the relevant msc.That all sounds good to me! The CSS in there at the moment is a pretty rough draft, but ideally, we'd have one piece of base CSS (although perhaps split across multiple actual CSS files) and then per-page tweaks for things that can't be reused.
From what I've found, this isn't in the spec and is a synapse-ism, and is what elements will use if a path isn't specified. We can use whatever endoint we want.
I noticed #801 was merged, so I rebased on it and am trying to use askama templates for login and consent webpages. There's a serious issue here : oxide-auth-axum is implemented as a synchronous backend, and porting it to async is non-trivial (see an old MR at their site - that's 1500 lines of code to port oxide-auth-actix to async). But askama is async, and the consent action needs its output in a sync function.
So I'm stuck here right now. I could try and implement that async port in the future, but that will probably take quite some time - and I'm going to have less free time in the weeks to come.
Besides, my main motivation to do this is to support external OIDC providers in the end. But I started thinking that such a feature would have no code in common with this MR.
So the alternative is either more work for the "act as OIDC provider" feature, or start another MR to implement OIDC delegation straight away.
Any opinions on that ?
For the record, someone already implemented async in oxide-auth with axum : https://github.com/mtelahun/axum-oauth
From what I understand, and what I can see in that PR, there is nothing in oxide-auth itself that needs to be changed to be asynchronous as there is no network or disk interaction within the library. That PR adds an example of how you can use asynchronous frameworks with the library.
askama, in contrast, is completely synchronous within its templates. To use asynchronous code you have to run it before rendering the templates and pass it into the template.
Regarding OIDC, this PR from what I understand is a necessary step, and third party OIDC will build upon it. It would be an addition of a new authentication method to the HTML login page. Although this has nothing in common with legacy OIDC (implemented as a different matrix-native authentication flow), that is depreciated and will stop working in some clients soon.
Don't worry about timelines, you're under absolutely no pressure here. I personally am pretty busy with exams right now!
Aha, I thought askama was asynchronous because I had introduced an async relay function, so I freaked out. Indeed, with your advice I succeeded in returning templates in oxide-auth's authentication flow.
The problem that I have now is that the returned login form is not clickable because of CSP policies. And I couldn't find a way to add headers to
OAuthResponses. ATM I'm looking into implementing anOwnerSolicitorthat would accept custom headers. It's a bit of a rabbit hole, but hopefully I'll manage something out of it.7f531034bf9a52b6cf9eGood work! I'm excited to see where this goes!
I assume you're running into issues with the default CSP. You'll need to set a CSP for the page using something like https://forgejo.ellis.link/continuwuation/continuwuity/src/branch/main/src/web/mod.rs#L32 rather than just directly returning the string.
Form actions don't support nonces (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/form-action) so you'll probably want
form-action 'self'In addition to the policy on the index page.9a52b6cf9ea78887d979I had to implement a custom OidcResponse that has CSP header capabilities. In the process I ditched the dependency on oxide-auth-axum. The MR now ships with askama templates support !
The result builds and passes areweoidcyet.com's implementation guide. Docstrings also have been rewritten with a newcomer's standpoint in mind.
a78887d979eef6e60826@ -0,0 +13,4 @@/// A Web response that can be processed by the OIDC authentication flow before/// being sent over.#[derive(Default, Clone, Debug)]pub struct OidcResponse {I'm not positive that
OidcResponseandOidcRequestshould live insrc/web- I first thought they belonged insrc/api/client/oidcbut that results in a cyclic dependency because that API depends onsrc/web/oidcitself.Maybe could they be buried deeper into the structure ?
I think you're right that they belong in API, or at least with the OIDC code. There shouldn't be a cyclic dependency as web doesn't depend on API or router.
If you carry on struggling, you could move the OIDC stuff into its own crate.
@nex proposed that we try to merge this PR in 0.5.0, so I don't want to move all OIDC stuff in a separate crate ATM, because it would imply more work than I can afford right now. My plan is to keep going with code cleanup. I'll keep that option in mind for later proposals.
eef6e608260c4917874eI haven't reviewed this for spec yet, just code quality. Ran into a bug I couldn't easily fix before I finished going through 'are we oidc yet'.
Ran clippy,
cargo +nightly fmtandtyposover it, which created the big diff.OidcRequest/Response should be located in the same crate as use of oxide-auth. It seems like dependencies have been added in many places to support code being spread out - should be avoided if possible.
Ignoring the templates themselves as I'm assuming they're placeholder for now.
@ -58,6 +58,10 @@##port = 8008# This item is undocumented. Please contribute documentation for it.Shouldn't be here. Check to see what
well_knowndoesfixed in 97b66d2f3e
@ -0,0 +77,4 @@/// Authorize the device based on the user's consent. If the user allows/// it to access their data, the client may request a token at the/// [super::token::token] endpoint.pub(crate) async fn authorize_consent(Testing going through https://areweoidcyet.com/ with the server running with the following config:
When we get to this point, we get a crash as this seems to return an empty body
Ahh I get it - if you set
it succeeds, right ? Then it's solved in 2baeba41
Nope, not solved. I fixed the issue with IP literals in particular in
continuwuation/continuwuity@7ff9d770e3, this is a different issueOK, obviously I was too quick using
OidcResponseinapi/client/oidc/discovery.rs. This specific issue should be fixed with-e09d60a6df- - discarded by 357c2335 .
I'm a bit jealous of your runtime logs, I only have access to a release binary, because I don't have enough disk space to compile debug builds. If I had access to that when debugging oxide-auth at the beggining, I'd have saved quite some hours !
Actually,
OidcResponseneeds a deeper rewrite. I thought I had copied over all functionalities from oxide-auth-axum'sOAuthResponse, but it appears I copied the wrong implementation. I'm on it now. BTW my machine built a debug build this night, thanks tonix --store ...and the workaround I published in #822Done in 357c2335 - rewrite of
OidcResponse'sIntoResponseimplementation. Should fix the issue at hand (the location header was not set), and a bunch of others.Can you confirm this build passes areweoidcyet.com's test page ?
It does now.
@ -0,0 +34,4 @@http::StatusCode::NOT_FOUND,ClientErrorBody::Standard {kind: ClientErrorKind::Unrecognized,message: "This homeserver doesn't do OIDC authentication.".to_owned(),'This homeserver has disabled OIDC authentication'
fixed in f4e0ff9e13
@ -0,0 +71,4 @@.unwrap(),),revocation_endpoint: issuer.join("_matrix/client/unstable/org.matrix.msc2964/revoke")Missing starting slash here?
Nice catch ! fixed in 0781453572
@ -117,6 +117,21 @@ pub fn build(router: Router<State>, server: &Server) -> Router<State> {.ruma_route(&client::get_protocols_route).route("/_matrix/client/unstable/thirdparty/protocols",get(client::get_protocols_route_unstable))// MSC2965 route.Nitpicking but include the MSC titles please
Right ! fixed in f4e0ff9e13
@ -274,0 +275,4 @@if auth.enable_oidc_login && config.well_known.client.is_none() {return Err!(Config("auth.enable_oidc_login","Oidc authentication is enabled but the well-known client is not set."OIDC / HTML URL shouldn't be tied to the client-server API URL. Can use it as a default, but should be a separate config option
I believed that until we implement delegation, the OIDC issuer should run at the same URL as the server. Should that be
config.well_known.server?And, if we make this a configurable default, then if the admin sets it to some other server, that server will expect all sorts of things like client provisioning. I naïvely thought we could avoid that, and implement delegation over standard OIDC servers in a later MR.
Maybe it's silly - or too ambitious. I don't get why Matrix did that overlay over OIDC. I hope Conduwuit can support standard OIDC issuers like Kanidm. Does that sound realistic ?
So this is not requesting delegation, but for the case where, for example, continuwuity is running on matrix.somedomain.com, but the user wants login pages, etc to appear on somedomain.com (and they've set their reverse proxy up correctly for that). For that to work, they'd need to be able to set the URL to a different value to the C/S URL
In fact, this but might not even be necessary, looks like it defaults to "Continuwuity" in the only place it's used

The well-known client is used in
src/api/client/oidc/discovery.rsto advertise the OIDC issuer. That's why I check on it at startup - if we are the OIDC issuer, we need an URL to advertise.That should be the well-known server instead, right ?
On the other hand, I wanted the login and consent page to display the current server name as a title. That's what the
hostnamevariable is for (that's insrc/api/client/oidc/login.rs). The well-known client was a hasty fill for the job. Is there a config variable that would be more adapted ? Or should we add eg anadvertised_servernamein[global.auth]?For displaying the server name, you want
config.server_name, which is what ends up being a part of the username.For the OIDC Discovery document, client is OK as a default, given that it's usually clients accessing those endpoints. I'll have a more in-depth look at that when I review for spec/functionality.
OK ! Added in 2baeba41 - proxy users would set that variable anyway, right ? So this settles that, doesn't it ?
Yep, you have to set
server_nameto start up the server@ -1882,0 +1892,4 @@/// The URL where the user is able to access the account management/// capabilities of the homeserver. Only used if `enable_oidc_login` is set./// Unset by default.pub enable_oidc_account_management: bool,Doc comment doesn't match here. Should have a default set.
I updated it to match the implementation in 97b66d2f3e - I guess the question to use a set or just a boolean is dependent on our other conversation on
src/core/config/check.rs.@ -111,6 +111,7 @@ webpage.workspace = truewebpage.optional = trueblurhash.workspace = trueblurhash.optional = trueoxide-auth.workspace = trueIs there a way we can avoid adding the oxide-auth dependency to so many crates? Reexporting necessary types, maybe
That would need a separate crate as you proposed.
@Jade do you think this dependency is acceptable as is for now ? It's true that it means more compile time for everybody, including people that don't use or want OIDC. Perhaps an alternative would be an OIDC feature flag ? I noticed that an LDAP feature flag landed in continuwuity meanwhile.
In my opinion, OIDC is the most mainstream future for Matrix authentication flow. It's both what Matrix specs advertise, and what brings more security features (clients never get a hand on user authentication material). So to me it makes sense to integrate it in the permanent codebase. I'm indeed very open to other clues though.
It's something that can be cleaned up later, don't worry about it.
BTW I'm sorry, I can't run
cargo +nightly fmton my machine right now, lack of resources here. I'll try to set it up.DW, I'm about to do that + fix some compile errors
@ -0,0 +48,4 @@pub fn preconfigured() -> Self {Self {registrar: Mutex::new(vec![Client::public(Before I forget about this old commit: this is purely illustrative, stating how to populate the initial client registry with an app. We should remove that sample client before long.
Done in the registrar rewrite a9246002
e09d60a6df357c233576@ -118,2 +118,4 @@.route("/_matrix/client/unstable/thirdparty/protocols",get(client::get_protocols_route_unstable))// MSC2965: OAuth 2.0 Authorization Server Metadata discovery..route("/_matrix/client/unstable/org.matrix.msc2965/auth_metadata",Any idea why Element X doesn't use the OIDC login endpoint ? I thought that maybe they don't use the unstable endpoints URLs anymore - the related MSCs were merged recently. Should I try to remove the unstable prefixes from the routes ?
You can try that, don't forget you can register the same handler on multiple routes.
I did try that (remove the unstable prefix from the OIDC discovery endpoint), the issue is still the same.
I must say I don't know what to do else. I did have some oauth knowledge before starting this MR because I already had implemented a client in react, but I'm definitely no expert in Matrix clients - I just used to run a conduwuit server for my family. This MR already contains all I can contribute at the moment, I'm afraid. Besides, I have plenty of paid work in another field coming up for the next two months, so I can't invest much time in debugging this issue.
If someone comes up with something else to try, I might find a bit of time for that though.
I'll have a look and see what I can figure out, but if I can't get it to work, I guess we can continue without that for now.
Taking a look at my Element X IOS Nightly logs, I see this:
2025-05-31T18:44:13.477754Z DEBUG matrix_sdk::http_client::native: Sending request num_attempt=1 | crates/matrix-sdk/src/http_client/native.rs:78 | spans: send{request_id="REQ-3" method=GET uri="https://matrix-client.matrix.org/_matrix/client/unstable/org.matrix.msc2965/auth_metadata"}I'll see if I can figure out why it's not making the request here
This seems to work now
9c7c7e7798bb9e8af4e0@ -0,0 +9,4 @@pub redirect_uri: Url,pub scope: String,pub state: String,pub code_challenge: String,Now that clients are confirmed to be connecting correctly (confirmed in
#development:continuwuity.org, I got mxtoken and Element X iOS to correctly detect and start using OIDC), there's an issue with the initial redirect to/authorize:Failed to deserialize query string: missing field code_challengeIn the initial request, this, and other fields are not provided, but required by this struct (and similar ones like LoginQuery).
The only five query params provided at the start of the flow are
client_id,response_type,redirect_uri,state, andscope. The rest are seemingly used later on?Both
code_challengeandcode_challenge_methodare necessary for PKCE, which is required as per the MSC on OIDC login. If a client is truly MSC2964 compatible, those parameters must be sent.The same MSC also appears to suggest the
response_modeparameter is required (it is explicitly mentioned multiple times without a default, and has the client check the server for compatibility with different modes), so it should also be sent every time. Which client wasn't sending these?Yeah, I seem to get different missing params depending on which OIDC-capable client I initiate from. I'll have to wait until we can figure out why Element Web doesn't work with this impl since debugging with Element X is suboptimal
@ty wrote in #810 (comment):
Specifically, Fractal isn't.
This suggests that the rust SDK isn't, probably worth a bug report to them at some point.
Hey, I just tried the OIDC login flow with both fractal and matrix-rust-sdk's
example-oauth-cli, and I can see theauthorizerequest bearscode_challengeandcode_challenge_methodin both cases (this is shown when usingconduwuit_api::client::oidc::authorize=tracein logs). I guess this was solved upstream since then.This discussion may be closed as far as I'm concerned. I leave it open so that @Jade can check they're OK with this.
I'm going to spend some time on this over the next week to see if we can get it working. It doesn't seem far off being finished.
Great ! I'm totally busy until the 8th of june, so I won't be able to help this week, but I'll try to follow your advances remotely - indeed, I think the MR is pretty close to the needed functionality, and I'm confident you'll find out how to make it work.
I guess the code will need some cleanup once it works, I think I'll focus on that when I'm back.
Thanks @nex
Got blindsided by some things that took far greater priority, apologies. Will definitely come to this when I get time.
9dbd0e654caa206e4f90Just re-ran this though https://areweoidcyet.com/client-implementation-guide/ and it works fine, so I'm going to start reaching out to relevant people to see if we can figure out why clients aren't using this correctly.
@ -107,0 +107,4 @@// external structure; separate sectionpub auth: Option<AuthConfig>,/// The UNIX socket conduwuit will listen on.You might wanna read through the diff for things like this by the way
Sorry, which diff ? What did I miss ?
Recently I thought that
authshould not be optional BTW, and it makes it tedious to find out what the auth system is in code.The PR diff; you accidentally replaced a Continuwuity with a conduwuit
Yeah it can work to have it not optional if you implement default so existing config isn't affected
@Jade wrote in #810 (comment):
Fixed in 287e44b1
@ -0,0 +32,4 @@fn try_from(value: OidcRequest) -> Result<Self, LoginError> {let body = value.body().expect("body in OidcRequest");let Some(username) = body.unique_value("username") else {I feel like this should be codegen-able (eg serde)
With these commits, the oidc authentication flow now succeeds with the Fractal client.
Details on the updates :
response_modefield. In Matrix this field can only contain the literal "fragment", which makes it superfluous for the clients. Fractal omits it, this fixes that.ClientMap, an implementation of a client registrar, which helps debugging with some tracing, and should help integrate its data in the database. I know strictly nothing about rocksdb and little more about databases in general, so I keep clear ATM.ClientMap.form-datainstructions.There are more issues to be solved, but now rather on the database side, would you dear reviewers give this MR a try ? I can witness it builds all right.
milestoning for 0.5.0 but really not sure if it'll make the cut this time around, more likely to be 0.6.0. Was gonna be in one of the earlier RCs but other priorities arose
OK - I have a working impl at home, I'll push it ASAP so you folks can assess that with latest developments.
81713273da416ffd4820Hey folks, long time no hear ! I just pushed some improvements over this PR :
Registrardirectly over the OIDCService, it works like a charm ! I added two segments in the db, one with the serialized oidc clients, one mapping device ids with client ids. I made wild guesses on the db descriptors though, I'm really incompetent in that field (and quite happy like that :)I rebased on current main and checked everything works as it should. And it does !
BTW, I tested the OIDC feature against matrix-rust-sdk's
example-oauth-cli, and it works. That's good news, because it's precisely the sdk used by fractal and element X. I succeeded in logging in using OIDC in fractal too using firefox. I had issues with chromium's CSP, but I can't remember the details. Element X still fails to propose the OIDC login flow, and I can't figure any clue on why.Disclaimer : I won't go further into debugging clients' login flow failures, mostly because it's extremely tedious with release builds (which I'm stuck with, as mentioned above). Changing a comma leads to almost half an hour of build time, which regularly fail short of disk space. In which case I'm forced to delete all build artifacts, and wait around an hour for a fresh build.
This being said, I'd like to work on some improvements to this PR, such as letting refresh tokens survive continuwuity's restart. Once that's done, the next thing that comes to mind (besides cleanup) is having account management pages in continuwuity.
Talking about cleanup, I'm sorry I can't format my commits (because it requires nightly rustc, which I can't afford either). Would there be a workaround ? Otherwise we'll have to rely on some generous soul that would reformat them and push them back (as one of my knowledge did in the past).
Don't worry too much about the formatting, we can always run a reformat and push back to your branch if necessary. All that matters is that gets done at some point before merge, until then it's not a big deal :)
That's fine - if this is implemented according to what is defined in the spec, and it's still not working on some clients, then I'm inclined to believe it's a bug in those clients and we can report that to them if needs be. We can also rebase out some commits like the one you added for debug logs before merging, don't worry too much about keeping a clean git log.
Do you want to do those in a separate PR, so we can get an initial implementation landed into the next release? You don't have to, but it might be worth considering given that we're aiming to get 0.5.0 out in the nearish future.
Yes, I'd really like that ! It would also be a great achievement for me that the last months' work landed in the current release. I'll check the todos I left here and there so we can assess what is landable right now.
@nex can you check if my mods to src/database/maps.rs are OK ? I wild-guessed the
Descriptorvalues, I have no idea if they fit.(Sorry, I don't know how to quote my commit's contents in Forgejo)
I found out how to quote my commits in Forgejo ! see below.
@ -436,1 +436,4 @@},Descriptor {name: "client_registrar",..descriptor::RANDOMI wild-guessed the
Descriptor's contents forclient_registraranddeviceid_clientidmap. Are they fit for the purpose ?Both of them look okay to me -- the extra options in
Descriptorare largely to optimize very hot tables.9c14f246ec96c069cd67Can this be used by other OIDC clients (other services able to act as OIDC clients running on the same or a different host, like CryptPad/NextCloud/OpenCloud/hopefully soon OwiCloud, Cryptomator Hub, Guacamole, EteSync, Vaultwarden+OIDC-addon etc.)? Kinda like a little substitute to Rauthy?
Can I use (configure) this now? How?
Or if not, can continuwuity be set up as a client to another OIDC provider (like Rauthy)? How?
@jh72de wrote in #810 (comment):
Hello, this PR will let continuwuity act as a Matrix identity provider, ie a special IdP with dynamic client registration and other subtle differences with usual OIDC IdP softwares. So as such, non-matrix clients will not be able to get a token from continuwuity.
The long-term objective (for me) is to support delegating identity provision to any standard OIDC provider, like eg rauthy or kanidm. This would allow to integrate continuwuity (and probably brand it), which should make it very attractive indeed. But :
As a result, I'd expect a standalone implementation around soon, but delegation will need investigation and, well, work, that is, time.
@lafleur wrote in #810 (comment):
Maybe it helps to take a look onto how others did it in other languages? Here it's done in Python, in a basic, but working manner (serving Matrix and Element Web/X as well as other clients like NextCloud): https://github.com/Jean28518/libre-workspace/tree/main/src/usr/lib/libre-workspace/portal/idm
I'm sorry, but to make it clear, implementing a standard OIDC identity provider inside Continuwuity is not on the agenda for me. This PR will only address Matrix clients' authorization.
Of course, when that's completed, all the authorization flows will be implemented, so you'll be free to propose another PR to let continuwuity act as a full-featured IdP.
I must say I don't think it would be a good idea though. Authorization is hard and complicated. Simply administering Kanidm will let you see that a correct implementation is non-trivial. I'm a partisan of the "do one thing and do it well" moto, and my ambition for Continuwuity is to be a complete, up-to-date Matrix server, eventually able to consume other IdP services. Not an overall IdP provider.
That's, of course, only my point of view. But as the initiator of this PR, I ask that this subject is discussed elsewhere, as it's not relevant to the work in progress here. If you want some more opinion from me, quote me in a feature request, I'll reach out as far as I can.
Here is the latest batch ! Implementing specially for you, dear reader :
conduwuit_oidc::endpoint::OidcEndpointtailored to Continuwuity's needs, putting togetherconduwuit_oidc::endpoint::OidcIssuerdefined over aDeviceStoretrait, andconduwuit_service::oidc::DbDeviceStore, all packed inconduwuit_service::oidc::Service, that providessrc/api/client/oidc/*One may note that login tokens are picked and stored with Continuwuity's main token ring. Other database ..er slices ? .. are added to keep track of the refresh tokens, and of the Oidc clients. The actuating is still a little messy, but the big picture is there.
I think I'm beginning to be happy with the core part (mostly the
conduwuit_oidc::endpointpart). But then there areTODOmarks all over the PR, that need specific solving. I'll ask for some advice on some in this discussion soon.Also, errors are very dirty. I'd need a primer on what to pick, and what to avoid reporting. Hopefully, oxide-auth's flows really behave like black boxes and return information that is deemed secure.
Last note, I had to implement some way of tracing the fact that a user is logged in - I opted for a clear, signed cookie only containing the user's id. We could go one step further and encrypt it, so that weak clients won't even spill our user ids. Any thoughts ?
@nex would you care to try this new version ? I think I clarified some flow steps, and it could be more well-behaved. Connection with Fractal is bliss, with redirection in Firefox. Chromium and Epiphany both choke on the CSP thing, couldn't wrap my head around that ATM. Pretty annoying in the end.
This WIP tag is beginning to itch me a little ...
Oh and I found a way to run cargo +nightly fmt, so I can do my own chores now :) Thanks for those who helped !
@lafleur wrote in #810 (comment):
Sure! I'll drop it into a deployment later today. I'll also see which part of the CSP needs loosening.
Still on my radar, struggling for time 😅
82e0859e14f4d558283dView command line instructions
Checkout
From your project repository, check out a new branch and test the changes.