Experimental Authorization-only mode #269

draxius · 2025-02-01T18:50:42Z

Add support for Authorization-Only mode:

Resolves heighandreas/authLdap#258
Supports a variety of login scenarios when combined with other WP plugins
Triggered by authLdap_authorize_only function in authLdap.php
Two new, EXPERIMENTAL settings (booleans) in admin UI (ExternalUsers, LocalWithExternal)
- Admin UI support already added
- Added in parallel with other Values definitions in Org_Heigl\AuthLdap\Value namespace
- Both settings are necessary for continued support of "local database" WP users
Included additional README file for details

Other changes made in support of this PR:

Patched a potential data disclosure vulnerability in login flow ($logger->log(var_export($loggedInUser, true));)
Added support for authLdap_get_server() to "reset" the binding when called
- Necessary to support "local user" scenario
Suppress PHP errors being thrown with user DN cannot be found during authorization flow
- Was causing silent failures in certain test cases

Happy to discuss any of the reasoning used here, make further modifications as necessary, or have this torn apart for further reuse if that's what's needed.

Add documentation for AuthZ-only scenario Second pass at heiglandreas#258 - this time updating 3.0.x

draxius · 2025-02-01T19:27:20Z

As a note during evaluation of this PR - as things currently stand, the authLdap_authorize_only function/filter will process even if authLDAP is not enabled. This is intentional, and allows scenarios where only "external" authentication is allowed as well as "external" and "local" auth are both allowed, while LDAP interaction is reserved solely for authorization purposes.

Obviously this can be further refined, but I wanted to get the existing code out there for review and discussion rather than making unilateral decisions on how that could be implemented.

heiglandreas · 2025-02-02T08:38:01Z

Thanks for the great work you did in the PullRequest!

There are several things I noticed though that I think make it more complicated that it needs to be.

The WordPress process of authentication is as far as I checked that the authenticate filter is calling all functions that were defined one after the other. The individual filter function takes 3 arguments: The result of the previous function, the username and the password.

So

when the first parameter is null, the previous function didn't do anything,
when the first parameter is a WP_User object, the previous function authenticated the user successful and
when the first parameter is a WP_Error object, the previous function ran into an error when authenticating.

This means that when a filter-function with a higher priority (lower $priority in the add_filter function) already authenticates a user they return a WP_User object. This then means that we get a WP_User object instead of a WP_Error or null as first parameter to the authldap_login method.

Right now we do not check whether the first parameter is already an authenticated users in that function. But actually we would not need to do authentication when we already have an authenitcated user.

So thinking about it, we would not need any new UI element at all to use the LDAP group-matching when a different authentication mechanism (SAML, OIDC, OAuth2...) was used. The plugins handling that login also needs to hook into the authenticate filter and has to return a WP_User object when authentication was successful. AuthLdap then needs to be invoked later than those plugins and when getting a WP_User object as first parameter to authldap_login skips the authentication and conversion to a WP_User object and only runs the Authorize part.

The only reason we might need a UI-switch would be to hide some of the configuration parts. But right now I would skip that.

authLdap.php

@@ -184,6 +190,8 @@
 	$authLDAPGroupOverUser = authLdap_get_option('GroupOverUser');
 	$authLDAPDoNotOverwriteNonLdapUsers = authLdap_get_option('DoNotOverwriteNonLdapUsers');
 	$authLDAPUseUserAccount = authLdap_get_option('UserRead');
+	$authLDAPExternalUsers = authLdap_get_option('ExternalUsers');


authLdap.php

@@ -193,6 +201,8 @@
 	$tStartTLSChecked = ($authLDAPStartTLS) ? ' checked="checked"' : '';
 	$tDoNotOverwriteNonLdapUsers = ($authLDAPDoNotOverwriteNonLdapUsers) ? ' checked="checked"' : '';
 	$tUserRead = ($authLDAPUseUserAccount) ? ' checked="checked"' : '';
+	$tExtChecked = ($authLDAPExternalUsers) ? ' checked="checked"' : '';


authLdap.php

@@ -193,6 +201,8 @@
 	$tStartTLSChecked = ($authLDAPStartTLS) ? ' checked="checked"' : '';
 	$tDoNotOverwriteNonLdapUsers = ($authLDAPDoNotOverwriteNonLdapUsers) ? ' checked="checked"' : '';
 	$tUserRead = ($authLDAPUseUserAccount) ? ' checked="checked"' : '';
+	$tExtChecked = ($authLDAPExternalUsers) ? ' checked="checked"' : '';
+	$tLocalWExtChecked = ($authLDAPLocalWithExternal) ? ' checked="checked"' : '';


authLdap.php

 * @conf boolean authLDAPDebug true, if debugging should be turned on
 * @conf string  authLDAPURI LDAP server URI
 *
 * @return Org_Heigl\AuthLdap\LdapList LDAP server object
 */
-function authLdap_get_server()
+function authLdap_get_server($reset = false)


authLdap.php

draxius · 2025-02-02T18:19:54Z

To address your comments more generally, here's the logic behind the changes as they currently stand, and why I implemented certain things the way that I did. I'll state up front that I am 100% on board with simplifying things where possible. I just don't see the places to remove complexity at this stage (with one possible exception I'll get to at the end).

The authLdap authenticate filter triggers at priority 10, default WP logins at priority 20. At least one of the plugins I tested with triggers at priority 21. So I set up the authLdap_authorize_only call at an arbitrarily high priority number (50) to basically force it to be "after all other auth is done". I needed to be sure it occurs after all other steps are completed in order to make sure that a) we actually have an authenticated user to operate on, and b) that user hasn't already been through the authorization step (hence the $authLDAPisLdapLogin global tracking.

The presence of the UI flags driving the options was, in part, to allow me to test different authenticate/authorization flows without having to change the code repeatedly, as well as to allow me to revert and recover settings back to the "release" state. They're also there to ensure that, should this functionality get integrated, it doesn't step on anyone's existing configurations. For example, if someone was to have an existing WP instance that uses SAML for authentication, and there happens to be an LDAP-based user match for that uid that isn't present in the groups as defined, forcing the authorization flow on that user would revert them to the Default Role as defined by authLdap rather than allowing them to keep their current roles. In short, I wanted to make sure that anyone who decides to experiment with this new functionality is doing so intentionally, rather than stumbling into an unexpected problem.

As another note, I also kept things separate in case there's a desired use case for a true "authorization only" mode for a WP site - authLdap installed, but with the "Enabled" flag off so that the username/password is never looked up against LDAP, but the group assignments in LDAP are used for authentication.

For simplification, I could see taking the duplicate authorization code (the block beginning if ($loggedInUser instanceof WP_User) {) and offloading that to a separate function/action to call. But I'm not seeing other places to trim this back down - not to say they're not present, just that I'm not really grasping it at the moment. Any recommendations/suggestions you might have are absolutely welcome.

As a final note - I'm currently ignoring the various automated checks until we've rolled in any necessary changes. Chasing down linter errors or other recommendations isn't useful if that stuff might end up going away anyway. 😉

heiglandreas · 2025-02-02T18:30:46Z

Moving authLdap to priority 50 would also be an option. Or adding a fumction to check on i stallation of any plugin whether they use the "authenticate" filter and set the authldap filter above by +1 of the max value?

The 10 is just an arbitrary number I set some 15 years ago 😁

An alternative would be to add a setting that lists the different authentication plugins and allows to inject the plugin somewhere in between or to the end or beginning....

draxius · 2025-02-02T19:34:34Z

Moving authLdap to priority 50 would also be an option. Or adding a fumction to check on i stallation of any plugin whether they use the "authenticate" filter and set the authldap filter above by +1 of the max value?

The 10 is just an arbitrary number I set some 15 years ago 😁

An alternative would be to add a setting that lists the different authentication plugins and allows to inject the plugin somewhere in between or to the end or beginning....

Did some quick local tests in my sandbox. As it stands, if I disable the new function and the settings, and bump the authLdap_login priority to 22 (one higher than the 21 I'm working with at the moment), it breaks things and tells me I've got an incorrect password for a local user. This is likely because, in the move to refactor to 3.0.0, the check for if ($user instanceof WP_User) was offloaded to the separate Authenticate function, so it no longer kicks the user out the login entire loop, just the Authenticate function (referencing Authenticate.php, lines 43-49).

Moving things to a later priority (with no other changes) would also introduce some weird issues if the CheckPW setting is enabled. If the user changes their LDAP password, their old password would still work (because local password storage would be evaluated first), and if that failed, the new (LDAP-checked) password would also work for logins. But that means if someone has a saved password in their browser, and changes things in LDAP due to a compromise, their account may still function as compromised in the WP context until they log in to the site and the database updates.

If, on the other hand, authLdap_login was to check for the an instance of WP_User again and kick them out of the login loop, then anything after that check would no longer be applied - including all of the authorization pieces of logic.

As to checking for other instances of an authenticate filter, I think that's more complex than it sounds. From what I've seen just over the last few weeks, different plugins define that very differently, and finding all instances where it might be used could lead to a lot of complicated logic that is evaluating code which is outside of your control. I don't know about you, but it sounds like a maintenance nightmare to me.

heiglandreas · 2025-02-02T19:53:47Z

That indeed sounds like a maintenance nightmare!

So: I think the best would be to actually let authldap call the authenticate filter twice. Once for the authentication with priority 10 as it already is. And then with the authorization part with priority 100.

That way the authentication will.continue to work as right now. And other authentications can also work as they do and then in the end we do the group mapping after all other authentications ran.

Requires to be able to enable or disable the two parts.

So we need three parts in the settings:

stuff that authentication needs (mail, name etc. attributes et al)
stuff that authorization needs (as already exists the use group role assignements)
stuff that both use like ldap-uri and user-filter

Does that sound sensible?

draxius · 2025-02-02T21:11:03Z

Sounds sensible to me, and what you scoped is close (although not identical) to what the PR is doing.

So: I think the best would be to actually let authldap call the authenticate filter twice. Once for the authentication with priority 10 as it already is. And then with the authorization part with priority 100.

This is essentially what's happening at priority 50, although I have it split into two distinct functions - the login, which only operates when the user is logging in via authLdap, and then the authorization happening at a later stage.

Requires to be able to enable or disable the two parts.

In the PR, the code treats the existing "Enable" flag as the on for enabling authLDAP authentication, and the new "ExternalUsers" flag for enabling authorization. The other new flag ("LocalWithExternal") is used for enabling/disabling existing 'local-only' accounts (those without any findable object in LDAP) entirely, as different scenarios might call for that functionality.

So we need three parts in the settings:

stuff that authentication needs (mail, name etc. attributes et al)

stuff that authorization needs (as already exists the use group role assignements)

stuff that both use like ldap-uri and user-filter

This is more or less how the settings are currently broken out, although I'm sure with the new functionality, you'll probably want to do some rearranging and possible variable renaming.

I'm going to take a crack at simplifying to code some more based on the above. Shouldn't be too long, provided I don't run into any big issues.

draxius · 2025-02-02T23:44:19Z

I think I've trimmed things down as much as I'm able to. +243 lines / -11 lines on the PR, but of the 243 added lines:

54 are in the new markdown document (which can, frankly, go away - it's mainly there to describe an overview of the original objectives and use cases)
26 are additions to the administration/settings page
56 (2x28) are the support files for returning values for the 2 new settings

That's 136 lines that aren't really functional changes in the back-end logic.

A bunch of the other +107/-11 is comments, whitespace, basic additions (importing settings in the Authorization loop, for example), and minor modifications to clean various things up/provide compatibility, so the overall change set is relatively minimal with regards to the code itself.

I put a bit of a spin on your recommendations, resulting in the following

Authentication and Authorization now trigger completely separately (at priorities 10 and 100, respectively) rather than looping through the same function twice.
- These functions do not share code, but the authorization function does need to know about LDAP logins to make a couple of determinations.
- authLdap_authorization will look very much like the "second half" of authLdap_login prior to the changes I submitted, which is absolutely intentional.
Settings were already in place, as described in my prior post, so I left that all unchanged for now, although how they get hooked is a little different with the main changes in that last commit.

It would absolutely be possible to embed an authLdap_authorization inside of authLdap_login and trigger it that way (with some attendant changes to the authorization function to prevent double-processing at priority 100), but I don't know if it makes much sense to do that since the current flow works as well.

How do you think things look after this latest set of deltas?

authLdap.php

heiglandreas

I still have some headaches with some of the code but the general idea is great! Thank you!

And the still working behat-tests show that your changes do not interrupt the currently existing flows (at least the main ones 🙈) which is pretty awesome!

heiglandreas · 2025-02-03T06:14:47Z

authLdap.php

 {
 	static $_ldapserver = null;
-	if (is_null($_ldapserver)) {
+	if (is_null($_ldapserver)|| $reset === "reset") {


When $reset is a boolean value this comparison will always be false

This actually isn't a boolean (I neglected to update the comment), but rather an explicit string of "reset". I should actually set a default value of null, or change it to a boolean - whichever will make the code behave better. But this should only trigger when explicitly called by line 363 $ldapServerList = authLdap_get_server("reset");.

heiglandreas · 2025-02-03T06:16:31Z

authLdap.php

@@ -254,7 +265,7 @@ function authLdap_get_server()
 * @param string $username
 * @param string $password
 * @param boolean $already_md5
- * @return boolean true, if login was successfull or false, if it wasn't
+ * @return WP_User, if login was successfull or false, if it wasn't


Thanks 😂

This should be WP_Uer|WP_Error|false to match the actual results, shouldn't it? ANd yes! It was definitely worse before! So: Thanks 😁

I suppose it should, shouldn't it? 😂

heiglandreas · 2025-02-03T06:20:37Z

authLdap.php

@@ -276,6 +285,14 @@ function authLdap_login($user, $username, $password, $already_md5 = false)
 		return $user;
 	}

+	// don't do anything when the password is not defined - assume an alternate method of authentication
+	if ($password == null) {


I would like to keep login-logic out of this method. Can we somehow handle this case in the Authenticate class?

I'm pretty sure I can just remove that block altogether - I might have left that one in for testing by mistake.

heiglandreas · 2025-02-03T06:22:55Z

authLdap.php

+	global $authLDAPisLdapLogin;
+	$authLDAPisLdapLogin = true;


Do we really need this? After all the process right now consists of 2 completely separate checks: Authenticate and Authorize. Why does the Authorize need to know where the authentication was done?

Yes, but it's a bit hard to articulate why. Basically, we have 3 potential sources of user authentication (generally speaking):

LDAP users

Internal WP users

"Other"/External users

Before we invoke Authorize, we need to know if we can recycle the existing LDAP connection - which will only work if we successfully authenticated via LDAP in the authLdap_login function. If we blindly reset the LDAP connection regardless of the authentication method (which we could do, of course), it overwrites the functionality of the UserRead flag.

So this global is there to ensure that a successful LDAP authentication continues to use the existing LDAP connection, and in all other cases, force it to reset because without that reset, the LDAP connection doesn't function.

Hm. Let me check why I introduced that flag. There was a reason. I'll get back to you on that later

heiglandreas · 2025-02-03T06:24:18Z

authLdap.php

+
+	// If this isn't already an LDAP user, force a reset in the LDAP server list, or LDAP lookups will fail
+	if (!($authLDAPisLdapLogin === true)) {
+		$ldapServerList = authLdap_get_server("reset");


This should be a boolean true, shouldn't it?

That or I need to adjust the default value, as mentioned above. Will ponder this a bit.

heiglandreas · 2025-02-03T06:28:33Z

authLdap.php

+	global $authLDAPisLdapLogin;
+	// Don't trigger if this isn't an LDAP login AND External Users aren't enabled
+	if (!($authLDAPisLdapLogin === true) && !authLdap_get_option('ExternalUsers')) {
+		authLdap_debug('User ineligible for LDAP Authorization ');
+		return $loggedInUser;
+	}
+
+	// If this isn't already an LDAP user, force a reset in the LDAP server list, or LDAP lookups will fail
+	if (!($authLDAPisLdapLogin === true)) {
+		$ldapServerList = authLdap_get_server("reset");
+		$ldapServerList->bind();


I'd ratehr move the logic into the Authorize class to have everything deciding whether the class should do something actually within that class. That makes future maintenance easier as there is only one place to modify when conditions should change.

As a matter of principle, I agree with you here. I was (and still am) struggling with how to make that happen without building in two-way dependency loops between Authorize and the core plugin script (which provides authLdap_get_server and builds the LDAP connections). Frankly, I'm not thrilled with the idea of using a global either, so I want to take some time to think about that piece. But I'm definitely open to suggestions on both fronts.

Those dependencies are a completely separate topic that I will address in a separate PR later. That will then also get rid of the WordPress functions scattered throughout the code and use "propper" dependency injection etc.

So for now: Don't worry about that.

heiglandreas · 2025-02-03T06:30:58Z

src/Authorize.php

-					$userInfoLdap[0][(string) $this->uidAttribute][0],
-					$userInfoLdap[0]['dn']
-				);
+				// Suppress PHP errors when no entries are returned


👍 Great thinking! Thanks!

heiglandreas · 2025-02-03T06:39:46Z

src/Authorize.php

+			// if the DN is not present in LDAP, and we both allow External users and local users
+			// alongside them, then just return the user object untouched so that roles are not changed
+			if (
+				( !isset($userInfoLdap[0]['dn']) || $userInfoLdap[0]['dn'] === null ) && 
+				$this->externalUsers->isEnabled() === true &&
+				$this->localWithExternal->isEnabled() === true
+			) {
+				$this->logger->log('user not found in LDAP, but permitted due to LocalWithExternal setting');
+				return $user;
+			}


I think we can skip that step.

There are several things happening right now:

The user has no role assigned in WordPress and we don'T have the user in LDAP: The user gets the default role assigned. (Which is necessary, otherwise they won't be able to do anything)

The user has a role assigned in WordPress and we don't have the user in LDAP: Depending on the setting "Overwrite WP-Roles" the existing roles get overwritten with the default role or the existing roles will stay as they are.

The user has no role assigned in WordPress and we have the user in LDAP: The user gets the LDAP-roles (or the default role as fallback) assigned.

The user has roles assigned in WordPress (or from a previous authentication step) and we have the user in LDAP: Depending on the "Overwrite WP-Roles" setting, the user gets the LDAP-roles (or the default role as fallback) assigned or keeps their current ones.

So this should all already be handled. Or am I missing something?

The user has a role assigned in WordPress and we don't have the user in LDAP: Depending on the setting "Overwrite WP-Roles" the existing roles get overwritten with the default role or the existing roles will stay as they are.

In this scenario, what happens without "Overwrite WP-Roles" set is that the existing roles get overwritten (or the user is denied access if that's the default). I added this clause specifically to handle the case where local users already existed with role assignments (we have a local "break glass" admin account on our WP instances that meets these conditions) and was getting locked out.

That's also the purpose of the "LocalWithExternal" flag - it basically says that, regardless of what the other LDAP settings are, if this is a true non-LDAP user, let them use their existing roles regardless of the Overwrite flag.

heiglandreas · 2025-02-03T06:45:19Z

src/Authorize.php

+		// Return an empty array if dn is not set or is null
+		if (!isset($dn) || $dn === null) {
+			return [];
+		}


Can we not move this to the top of the function? That way we can immediately return an empty array without having to invoke any (expensive) WordPress functions.

And we should be able to remove the isset here as the variable is definitely set as it is a function parameter.

But we might need to adapt the signature to allow null besides string. Or we pass an empty string instead of the null and then check for that.

Can we not move this to the top of the function? That way we can immediately return an empty array without having to invoke any (expensive) WordPress functions.

Oh, for sure. I just shoved that in to resolve an error and didn't pay much mind to what was before it - I just needed it prior to the try/catch to resolve an error.

And we should be able to remove the isset here as the variable is definitely set as it is a function parameter.

You're likely correct on the isset - I was going fast out of frustration when I added this bit. 😅

But we might need to adapt the signature to allow null besides string. Or we pass an empty string instead of the null and then check for that.

I think a $dn === null should be sufficient without any other tweaking? But I can definitely run through some tests when I make the next set of changes.

heiglandreas · 2025-02-03T06:48:09Z

view/admin.phtml

+                            Shall we try to find the user in LDAP even if they logged in through a different mechanism (SAML, OIDC, social logins, local accounts, etc)? CAUTION: This has the potential to break access for users,
+			                depending on the configuration of other settings.
+                        </p>
+                        <p class="description">This should only be checked if you know what you are doing! THIS WILL TRIGGER EVEN IF LDAP AUTHENTICATION IS DISABLED.</p>


The "Enable AuthLDAP" should enable the whole plugin! Not only the Authentication. It is a safety catch to disable all LDAP-interaction in case that becomes necessaary.

To disable the authentication part of authLdap we need a separate flag to "Disable Authentication via LDAP"

I'm 100% fine with this. Wasn't sure how you wanted to approach things, so I didn't add that in, but you're absolutely right - that's definitely needed as a safety switch.

draxius · 2025-02-03T09:07:24Z

Will respond to the comments above now, and then take a look at your replies and any necessary code changes tomorrow, as it's late for me. I just didn't want to leave this unanswered before I went to bed. 😅

draxius · 2025-02-07T03:34:29Z

My day job got a little crazy this week, so updates were slow going to say the least. I'm working on an additional commit that addresses the following based on your feedback and stuff from the code scans. Everything has been tested on my local sandbox instance before I even wrote it on the list here, so these aren't blind changes.

$reset for authLdap_get_server() converted to a boolean
Expanded comment for returns on authLdap_login
Moved if ($password == null) check into Authenticate.php
Moved check for null $dn in groupmap() (from Authorize.php) to top of function to save on expensive lookups and simplified
- As a note on this - testing with a user resident in the WP database shows that a $dn === null check seems to be sufficient here
Added check for the overall plugin "Enabled" flag to authLdap_authorization
Removed $username input from authLdap_authorization call

Things that I haven't touched yet:

Add option to disable LDAP Authentication while allowing Authorization to continue
Figure out a way to not rely on the $authLDAPisLdapLogin global, and move it into the Authorization logic (this was deferred for now)
- This is tricky enough in terms of logic that I almost want to diagram out the flow to figure out how it might be doable
Anything else from the prior comments that I might have missed, and isn't in this list, isn't jumping out at me at the moment - please don't feel bad about reminding me of them.

authLdap.php

+		authLdap_debug(
+			'LDAP disabled in AuthLDAP plugin options (use the first option in the AuthLDAP options to enable it)'
+		);
+		return $user;


draxius · 2025-02-21T15:10:58Z

Just as a note here - latest commit above was a standard merge of the 3.1.0 release into the PR's branch - no other changes have been introduced at this time.

It's been a couple of weeks since we've talked about anything regarding this PR, so I'm not sure if we should resume the conversation or basically "start over" in terms of discussing the change set. But I'm happy to answer any questions, clarify what's happening, or make additional alterations as needed.

Thanks again for entertaining this entire effort.

heiglandreas · 2025-02-21T15:19:53Z

I've got "going through the changes" on my agenda for the weekend!

draxius added 4 commits January 31, 2025 11:01

Allow 'external' users to get roles (modifies 3.0.0)

979f202

Merge branch 'heiglandreas:master' into authz-3-adjustments

d2ffbbf

Merge branch 'heiglandreas:master' into authz-3-adjustments

3abdc5e

Update global declaration to be authLdap-specific

0c8ab88

Add documentation for AuthZ-only scenario Second pass at heiglandreas#258 - this time updating 3.0.x

github-advanced-security bot found potential problems Feb 2, 2025

View reviewed changes

Separate entirely and delay authorization against LDAP

a52b07a

github-advanced-security bot found potential problems Feb 3, 2025

View reviewed changes

authLdap.php Fixed Show fixed Hide fixed

heiglandreas reviewed Feb 3, 2025

View reviewed changes

Some cleanup and reorganization based on Andreas's feedback

7443279

github-advanced-security bot found potential problems Feb 17, 2025

View reviewed changes

Merge branch 'heiglandreas:master' into authz-3-adjustments

1907f61

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Experimental Authorization-only mode #269

Experimental Authorization-only mode #269

draxius commented Feb 1, 2025 •

edited

Loading

draxius commented Feb 1, 2025

heiglandreas commented Feb 2, 2025

draxius commented Feb 2, 2025

heiglandreas commented Feb 2, 2025

draxius commented Feb 2, 2025

heiglandreas commented Feb 2, 2025

draxius commented Feb 2, 2025

draxius commented Feb 2, 2025

heiglandreas left a comment •

edited

Loading

heiglandreas Feb 3, 2025

draxius Feb 3, 2025

heiglandreas Feb 3, 2025

draxius Feb 3, 2025

heiglandreas Feb 3, 2025

draxius Feb 3, 2025

heiglandreas Feb 3, 2025

draxius Feb 3, 2025

heiglandreas Feb 3, 2025

heiglandreas Feb 3, 2025

draxius Feb 3, 2025

heiglandreas Feb 3, 2025

draxius Feb 3, 2025

heiglandreas Feb 3, 2025

heiglandreas Feb 3, 2025

heiglandreas Feb 3, 2025

draxius Feb 3, 2025

heiglandreas Feb 3, 2025

draxius Feb 3, 2025

heiglandreas Feb 3, 2025

draxius Feb 3, 2025

draxius commented Feb 3, 2025

draxius commented Feb 7, 2025

draxius commented Feb 21, 2025

heiglandreas commented Feb 21, 2025

Experimental Authorization-only mode #269

Are you sure you want to change the base?

Experimental Authorization-only mode #269

Conversation

draxius commented Feb 1, 2025 • edited Loading

draxius commented Feb 1, 2025

heiglandreas commented Feb 2, 2025

draxius commented Feb 2, 2025

heiglandreas commented Feb 2, 2025

draxius commented Feb 2, 2025

heiglandreas commented Feb 2, 2025

draxius commented Feb 2, 2025

draxius commented Feb 2, 2025

heiglandreas left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

draxius commented Feb 3, 2025

draxius commented Feb 7, 2025

draxius commented Feb 21, 2025

heiglandreas commented Feb 21, 2025

draxius commented Feb 1, 2025 •

edited

Loading

heiglandreas left a comment •

edited

Loading