Hri7566
/
gitea
1
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity
gitea/modules/auth/ldap
History
zeripath 704da08fdc
Better logging (#6038) (#6095) 
* Panic don't fatal on create new logger

Fixes #5854

Signed-off-by: Andrew Thornton <art27@cantab.net>

* partial broken

* Update the logging infrastrcture

Signed-off-by: Andrew Thornton <art27@cantab.net>

* Reset the skip levels for Fatal and Error

Signed-off-by: Andrew Thornton <art27@cantab.net>

* broken ncsa

* More log.Error fixes

Signed-off-by: Andrew Thornton <art27@cantab.net>

* Remove nal

* set log-levels to lowercase

* Make console_test test all levels

* switch to lowercased levels

* OK now working

* Fix vetting issues

* Fix lint

* Fix tests

* change default logging to match current gitea

* Improve log testing

Signed-off-by: Andrew Thornton <art27@cantab.net>

* reset error skip levels to 0

* Update documentation and access logger configuration

* Redirect the router log back to gitea if redirect macaron log but also allow setting the log level - i.e. TRACE

* Fix broken level caching

* Refactor the router log

* Add Router logger

* Add colorizing options

* Adjust router colors

* Only create logger if they will be used

* update app.ini.sample

* rename Attribute ColorAttribute

* Change from white to green for function

* Set fatal/error levels

* Restore initial trace logger

* Fix Trace arguments in modules/auth/auth.go

* Properly handle XORMLogger

* Improve admin/config page

* fix fmt

* Add auto-compression of old logs

* Update error log levels

* Remove the unnecessary skip argument from Error, Fatal and Critical

* Add stacktrace support

* Fix tests

* Remove x/sync from vendors?

* Add stderr option to console logger

* Use filepath.ToSlash to protect against Windows in tests

* Remove prefixed underscores from names in colors.go

* Remove not implemented database logger

This was removed from Gogs on 4 Mar 2016 but left in the configuration
since then.

* Ensure that log paths are relative to ROOT_PATH

* use path.Join

* rename jsonConfig to logConfig

* Rename "config" to "jsonConfig" to make it clearer

* Requested changes

* Requested changes: XormLogger

* Try to color the windows terminal

If successful default to colorizing the console logs

* fixup

* Colorize initially too

* update vendor

* Colorize logs on default and remove if this is not a colorizing logger

* Fix documentation

* fix test

* Use go-isatty to detect if on windows we are on msys or cygwin

* Fix spelling mistake

* Add missing vendors

* More changes

* Rationalise the ANSI writer protection

* Adjust colors on advice from @0x5c

* Make Flags a comma separated list

* Move to use the windows constant for ENABLE_VIRTUAL_TERMINAL_PROCESSING

* Ensure matching is done on the non-colored message - to simpify EXPRESSION
 		2019-04-02 08:48:31 +01:00
..
README.md Gogs -> Gitea (#2909) 2017-11-14 08:55:57 +08:00
ldap.go Better logging (#6038) (#6095) 2019-04-02 08:48:31 +01:00

README.md

Gitea LDAP Authentication Module

About

This authentication module attempts to authorize and authenticate a user against an LDAP server. It provides two methods of authentication: LDAP via BindDN, and LDAP simple authentication.

LDAP via BindDN functions like most LDAP authentication systems. First, it queries the LDAP server using a Bind DN and searches for the user that is attempting to sign in. If the user is found, the module attempts to bind to the server using the user's supplied credentials. If this succeeds, the user has been authenticated, and his account information is retrieved and passed to the Gogs login infrastructure.

LDAP simple authentication does not utilize a Bind DN. Instead, it binds directly with the LDAP server using the user's supplied credentials. If the bind succeeds and no filter rules out the user, the user is authenticated.

LDAP via BindDN is recommended for most users. By using a Bind DN, the server can perform authorization by restricting which entries the Bind DN account can read. Further, using a Bind DN with reduced permissions can reduce security risk in the face of application bugs.

Usage

To use this module, add an LDAP authentication source via the Authentications section in the admin panel. Both the LDAP via BindDN and the simple auth LDAP share the following fields:

  • Authorization Name (required)

    • A name to assign to the new method of authorization.

  • Host (required)

    • The address where the LDAP server can be reached.
    • Example: mydomain.com

  • Port (required)

    • The port to use when connecting to the server.
    • Example: 636

  • Enable TLS Encryption (optional)

    • Whether to use TLS when connecting to the LDAP server.

  • Admin Filter (optional)

    • An LDAP filter specifying if a user should be given administrator privileges. If a user accounts passes the filter, the user will be privileged as an administrator.
    • Example: (objectClass=adminAccount)

  • First name attribute (optional)

    • The attribute of the user's LDAP record containing the user's first name. This will be used to populate their account information.
    • Example: givenName

  • Surname attribute (optional)

    • The attribute of the user's LDAP record containing the user's surname This will be used to populate their account information.
    • Example: sn

  • E-mail attribute (required)

    • The attribute of the user's LDAP record containing the user's email address. This will be used to populate their account information.
    • Example: mail

LDAP via BindDN adds the following fields:

  • Bind DN (optional)

    • The DN to bind to the LDAP server with when searching for the user. This may be left blank to perform an anonymous search.
    • Example: cn=Search,dc=mydomain,dc=com

  • Bind Password (optional)

    • The password for the Bind DN specified above, if any. Note: The password is stored in plaintext at the server. As such, ensure that your Bind DN has as few privileges as possible.

  • User Search Base (required)

    • The LDAP base at which user accounts will be searched for.
    • Example: ou=Users,dc=mydomain,dc=com

  • User Filter (required)

    • An LDAP filter declaring how to find the user record that is attempting to authenticate. The '%s' matching parameter will be substituted with the user's username.
    • Example: (&(objectClass=posixAccount)(uid=%s))

LDAP using simple auth adds the following fields:

  • User DN (required)

    • A template to use as the user's DN. The %s matching parameter will be substituted with the user's username.
    • Example: cn=%s,ou=Users,dc=mydomain,dc=com
    • Example: uid=%s,ou=Users,dc=mydomain,dc=com

  • User Filter (required)

    • An LDAP filter declaring when a user should be allowed to log in. The %s matching parameter will be substituted with the user's username.
    • Example: (&(objectClass=posixAccount)(cn=%s))
    • Example: (&(objectClass=posixAccount)(uid=%s))