An error occurred fetching the project authors.
- 08 Sep, 2015 1 commit
-
-
Douwe Maan authored
-
- 29 Aug, 2015 1 commit
-
-
Douwe Maan authored
-
- 21 Aug, 2015 1 commit
-
-
Joel Koglin authored
-
- 14 Apr, 2015 2 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
- 13 Apr, 2015 1 commit
-
-
Jacob Vosmaer authored
-
- 09 Apr, 2015 1 commit
-
-
Robert Speicher authored
Lets Rails autoload these files by name
-
- 06 Apr, 2015 1 commit
-
-
Douwe Maan authored
-
- 29 Jan, 2015 1 commit
-
-
Dmitriy Zaporozhets authored
* method #changed? also tracks changes of identites (fixes issue with email mapping) * find ldap identity before initialize one
-
- 04 Dec, 2014 2 commits
-
-
Valery Sizov authored
-
Valery Sizov authored
-
- 14 Oct, 2014 2 commits
-
-
Jan-Willem van der Meer authored
-
Jan-Willem van der Meer authored
-
- 13 Oct, 2014 1 commit
-
-
Jan-Willem van der Meer authored
-
- 10 Oct, 2014 1 commit
-
-
Jan-Willem van der Meer authored
-
- 08 Sep, 2014 2 commits
-
-
Jan-Willem van der Meer authored
-
Jan-Willem van der Meer authored
-
- 04 Sep, 2014 1 commit
-
-
Jan-Willem van der Meer authored
-
- 03 Sep, 2014 2 commits
-
-
Jan-Willem van der Meer authored
Still in need of some proper cleanup
-
Jan-Willem van der Meer authored
-
- 01 Sep, 2014 1 commit
-
-
Jan-Willem van der Meer authored
-
- 29 Aug, 2014 1 commit
-
-
Jacob Vosmaer authored
This method existed to allow LDAP users to take over existing GitLab accounts if the part before the '@' of their LDAP email attribute matched the username of an existing GitLab user. I propose to disable this behavior in order to prevent unintended GitLab account takeovers. After this change it is still possible to take over an existing GitLab account with your LDAP credentials, as long as the GitLab account email address matches the LDAP user email address.
-
- 11 Jun, 2014 1 commit
-
-
Marin Jankovski authored
-
- 28 Mar, 2014 1 commit
-
-
Jacob Vosmaer authored
Before there was a bug in omniauth-ldap which prevented samaccountname showing up as a possible username for new LDAP users. Thanks to upstream fixes, we no longer need to work around this bug.
-
- 10 Mar, 2014 1 commit
-
-
Dmitriy Zaporozhets authored
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
- 18 Feb, 2014 1 commit
-
-
Jakub Jirutka authored
-
- 19 Jan, 2014 1 commit
-
-
skv authored
-
- 01 Dec, 2013 1 commit
-
-
Sytse Sijbrandij authored
-
- 03 Nov, 2013 1 commit
-
-
Elias Mårtenson authored
The blocked? method is used to check whether a user exists in LDAP. Prior to this change, if the LDAP server had more objects below the one pointed to by the DN, those objects would also be picked up by the search, causing the method to determine the user should be blocked. One case where this can happen is when using Active Directory and a user have a mobile phone assigned. In this case, Exchange will add an entry called ExchangeActiveSyncDevices under the users entry. The user-visible behaviour is then that a user loses Gitlab access when he enables a mobile device. This fix sets the search scope to BaseObject in order to ensure that only the user itself is returned.
-
- 07 Oct, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 23 Sep, 2013 2 commits
-
-
Izaak Alpert authored
fixed a test a broke in the configurable theme PR Change-Id: Id894506941bc01ab0d259d48ca7ff9b80bb2c57e
-
Izaak Alpert authored
-when logging in if users are allowed to login with just usernames in ldap we will update uid of the user if their uid is out of date Conflicts: spec/lib/auth_spec.rb Change-Id: Ia171b3d5133da86edc18c0d08ecfaf6a174f2574
-
- 03 Sep, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
-
- 02 Sep, 2013 2 commits
-
-
Dmitriy Zaporozhets authored
-
Dmitriy Zaporozhets authored
-