Ldap still has error codes though

wait

what

nvm I got confused bc of a typo.

It seems slightly non standard

But I think we can add it

Didn't know that.

It kinda seems like authelia does not support the forced password reset and closed the Issue for containing a workaround without stating that fact. Seems like I will have to manage the password reset flow otherwise. Then I'll start with #352 first (which is also more important to me personally).

Some more investigations shows that we probably need to rewrite/restructure the search code to be better prepared for working with the hierarchical nature of LDAP. This in no way means we move in the direction of the LDAP protocol hell, but in the current state it is quite hard to handle the different search scopes/filters/hierarchy levels. For example, if an LDAP browser does a

-b dc=example,dc=com -s one

, the server should only show

ou=People

and

ou=Groups

as the scope(depth) is one. However in the current state, this gets ignored and the servers returns all entries instead, which is the main cause of issue with the LDAP browsers I tested. I tried some implementations without changing much of the existing code (basically intercepting) but this gets dirty very quickly. (Also the way subschema requests are intercepted now can be done a bit more cleany if we have one central place where the request is processed). Any opionions on this matter?:) ( @nitnelave )

I agree. The current "structure" was done to be able to respond to the few queries that were interesting at the time, but in no way did it attempt to respond to everything it should. Feel free to propose a restructure !

@Kumpelinus feel free to shout out if you need help! I can also put copilot on the job if you want

Thank you. I just started seeing if Copilot can fix it myself (using my own Account). Looks good so far 🙂

@T0by you might be interested in https://github.com/ericschmar/moribito

Hmmm that might be useful indeed

toml
[trusted_header_options]
enabled = true
header_name = "Remote-User"
logout_url = "https://auth.example.com/logout"
trusted_cidrs = ["127.0.0.0/8", "::1/128"]

idk. I don't like this. Maybe I should make it be trusted_proxies or smth? And the section name is also a bit meh.

@nitnelave what do you think?

Just saw that you are online anyways 🙂

I like trusted proxies

I'm only marginally online, taking care of the kid

All good 🙂

Yay! They fixed the integration! I can now merge my own copilot PRs!

Hello all, I have been working a PR to integrate password policy (I know bad feature and everyone will hate me). I have the logic down. However my lack of Rust knowledge has me spinning. I am trying to define and endpoint so set-password binary can hit the lldap server and receive back the active password policy. To this end, I am trying to figure out where I should define the graphQL query. The schema file seems to be empty and the server/src/graphql_server appears to be pointing crates/graphql-server/src/api. Is this close to correct?

Basically I have added this struct inside the Configuration struct in server/src/configuration.rs. I would like the be able to query it from set-password.

#[derive(Debug, Clone, Deserialize, Serialize)]
#[serde(default)]
pub struct PasswordPolicyOptions {

    // Minimum total length of the password
    // Recommended Size is 8
    pub min_length: usize,

    // Minimum number of uppercase characters required.
    // 0 means not required.
    // This is not recommended, but only implemented for various bad policy requrements
    pub min_uppercase: usize,

    /// Minimum number of lowercase characters required.
    // 0 means not required.
    // This is not recommended, but only implemented for various bad policy requrements
    pub min_lowercase: usize,

    // Minimum number of digits required.
    // 0 means not required.
    // This is not recommended, but only implemented for various bad policy requrements
    pub min_digits: usize,

    // Minimum number of special characters required
    // This is not recommended, but only implemented for various bad policy requrements
    pub min_special: usize,

    // Set of allowed special characters
    // If min_special is zero, characters will not be looked at
    // This is not recommended, but only implemented for various bad policy requrements
    pub allowed_specials: Vec<char>,
}

I think you should reuse the configuration endpoint, like the web frontend

Oh even better. Thank you.

Okay I am pretty sure I am done, but want to do some additional testing. Would you like me to open a new PR or use the old one?

Let's make a new one

Opened the PR. Thanks again for all the work on this. I know it is during the work week and whatnot so whenever you have time over the next couple weeks I'll be around to answer questions. I implemented this because I think lldap would have been a great option for an organization I was helping out, but couldn't due to the silly requirements. So hopefully if anyone else falls into this category it can work for them in the future. Also sorry I'm advance for my bad rust. Tried to follow how the repo was doing things as best I could.