CDash icon indicating copy to clipboard operation
CDash copied to clipboard

LDAP_BASE_DN formatting in .env

Open notjustanyjoe opened this issue 4 years ago • 4 comments

I've been able to manually configure CDash to work with ldap but I've found that i've had to go back into the .env file to correct formatting after running the php artisan config:migrate command.

Example of the LDAP_BASE_DN in .env before the migrate command. LDAP_BASE_DN='cn=users,dc=example,dc=com' How the line is changed after running the migrate command. LDAP_BASE_DN='cn I've tried adding single ' and double " around the DN but i'm not having any success with keeping the string with the = intact.

notjustanyjoe avatar Oct 29 '20 15:10 notjustanyjoe

Thanks for letting us know. I'll take a closer look and update the migration & associated tests if need be.

Have you tried no quotes at all? That's worked for me in the past. eg:

LDAP_BASE_DN=ou=myorg,dc=cdash,dc=mycorp,dc=com

zackgalbreath avatar Nov 13 '20 14:11 zackgalbreath

@notjustanyjoe thanks so much for filing this, I've been trying to get cdash 3.0.3 working and this was the cause of all my LDAP logins failing!

@zackgalbreath so I can confirm this bug still exists in the 3.0.3 release.

seanm avatar Mar 02 '21 23:03 seanm

@zackgalbreath what's the expected behaviour if I:

rm .env
cp .env.example .env
php artisan key:generate
php artisan config:migrate
cat .env

I don't see any of the ldap variables in there at all now! I also see:

GEOLOCATE_IP_ADDRESSES=

Shouldn't there be an =false or =true there?

I can share my exact config.local.php privately by email if that'd help.

seanm avatar Mar 03 '21 01:03 seanm

Thanks for letting us know. I'll take a closer look and update the migration & associated tests if need be.

Have you tried no quotes at all? That's worked for me in the past. eg:

LDAP_BASE_DN=ou=myorg,dc=cdash,dc=mycorp,dc=com

I have tried without the quotes and still get the same behavior. I just don't add my ldap info into the .env until after the I run the migrate command. It's part of an ansible playbook that I run so it's a workaround.

I haven't tried with v3.0.3 yet but as @seanm mentioned, i'm guessing it's still a current behavior.

notjustanyjoe avatar Mar 03 '21 02:03 notjustanyjoe