The filters for user and group searches hadn't been included in our LDAP
tests. Now they are.
The concrete test cases are somewhat contrived, but that shouldn't
matter too much. Also note that the example queries I've used are not
supported in AD: https://stackoverflow.com/a/10043452
Signed-off-by: Stephan Renatus <srenatus@chef.io>
Make expiry of auth requests configurable
This is a band-aid against #1292
I did not change the default from 24h, but I think it should be much lower for safety.
postgres: expose database/sql tunables
Fixes#1354.
I've not had a need for MaxIdleConns and ConnMaxLifetime myself, but it felt weird to only expose of the three settings.
Makefile: cleanups for newer versions of Go
Go 1.9 removed "./..." matching the vendor directory while Go 1.10 added
build and test caching. This means we no longer need to grep out
vendored matches (except for golint which doesn't implement the same
behavior), and we no longer need to pre-build packages with "go build -i".
https://golang.org/doc/go1.9#vendor-dotdotdothttps://golang.org/doc/go1.10#build
- adapted TestUnmarshalConfig to ensure the fields are read in
- added a test to see that at least MaxOpenConns works:
- this is only exposed through (*db).Stats() in go 1.11, so this test
has a build tag
- the other two configurables can't be read back, so we've got to
trust that the mechanism works given the one instance that's tested..
Signed-off-by: Stephan Renatus <srenatus@chef.io>
Add 'both' option to use team name AND slug in TeamNameField
This allows the connector to be configured with both so that both team names and slugs can be returned in the groups. This makes configuring teams in an application a bit more foolproof; we would often have confusion over whether the team name or slug should be given by the user, so it's easier to just allow both, since collisions shouldn't be possible anyway.
Use pq connection parameters instead of URLs for postgres connections
This enables the use of socket paths like /var/run/postgresql for the 'host' instead of requiring TCP. Also, we know allow using a non-default port.
Fixes#1304, if we want to be harsh.
However, I think if it was the user's intention to pass two certs, and
the second one couldn't be read, that shouldn't just disappear. After
all, when attempting to login later, that might fail because the
expected IdP cert data isn't there.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
Some directory servers (I think it's Oracle) return
Constraint Violation: Exceed password retry limit. Account locked.
when attempting to login too many times. While constraint violation can
mean many things, we're checking this as an error on BIND, so it's
more likely that something like this has happened than any other thing.
Hence, we should treat it as an "incorrect password" situation, not an
internal error.
It would of course be preferrable to surface more information about this
precise error (and similar ones), but I think this is beyond this small
change.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
Before, you could not POST your credentials to a password-connector's
endpoint without GETing that endpoint first. While this makes sense for
browser clients; automated interactions with Dex don't need to look at
the password form to fill it in.
A symptom of that missing GET was that the POST succeeded (!) with
login successful: connector "", username="admin", email="admin@example.com", groups=[]
Note the connector "". A subsequent call to finalizeLogin would then
fail with
connector with ID "" not found: failed to get connector object from storage: not found
Now, the connector ID of an auth request will be updated for both GETs
and POSTs.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
This way, the user who has selected, say, "Log in with Email" can make up
their mind, and select a different connector instead.
However, if there's only one connector set up, none of this makes sense -- and
the link will thus not be displayed.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
This allows users of the LDAP connector to give users of Dex' login
prompt an idea of what they should enter for a username.
Before, irregardless of how the LDAP connector was set up, the prompt
was
Username
[_________________]
Password
[_________________]
Now, this is configurable, and can be used to say "MyCorp SSO Login" if
that's what it is.
If it's not configured, it will default to "Username".
For the passwordDB connector (local users), it is set to "Email
Address", since this is what it uses.
Signed-off-by: Stephan Renatus <srenatus@chef.io>
Stephan Renatus