| | |
|---|
| | | #### User Roles
|
|---|
| | | There are two actual *roles* in Gitblit: *#admin*, which grants administrative powers to that user, and *#notfederated*, which prevents an account from being pulled by another Gitblit instance. Administrators automatically have access to all repositories. All other *roles* are repository names. If a repository is access-restricted, the user must have the repository's name within his/her roles to bypass the access restriction. This is how users are granted access to a restricted repository.
|
|---|
| | |
|
|---|
| | | ## Authentication and Authorization Customization
|
|---|
| | | ## Alternative Authentication and Authorization
|
|---|
| | |
|
|---|
| | | ### Customize Authentication Only
|
|---|
| | | ### LDAP Authentication
|
|---|
| | | *SINCE 1.0.0*
|
|---|
| | |
|
|---|
| | | LDAP can be used to authenticate Users and optionally control Team memberships. When properly configured, Gitblit will delegate authentication to your LDAP server and will cache some user information in the usual users file (.conf or .properties).
|
|---|
| | |
|
|---|
| | | When using the LDAP User Service, new user accounts can not be manually created from Gitblit. Gitblit user accounts are automatically created for new users on their first succesful authentication through Gitblit against the LDAP server. It is also important to note that the LDAP User Service does not retrieve or store user passwords nor does it implement any LDAP-write functionality.
|
|---|
| | |
|
|---|
| | | To use the *LdapUserService* set *realm.userService=com.gitblit.LdapUserService* in your `gitblit.properties` file or your `web.xml` file and then configure the *realm.ldap* settings appropriately for your LDAP environment.
|
|---|
| | |
|
|---|
| | | #### Example LDAP Layout
|
|---|
| | | 
|
|---|
| | |
|
|---|
| | | Please see [ldapUserServiceSampleData.ldif](https://github.com/gitblit/gitblit/blob/master/tests/com/gitblit/tests/resources/ldapUserServiceSampleData.ldif) to see the data in LDAP that reflects the above picture.
|
|---|
| | |
|
|---|
| | | #### Gitblit Settings for Example LDAP Layout
|
|---|
| | | The following are the settings required to configure Gitblit to authenticate against the example LDAP server with LDAP-controlled team memberships.
|
|---|
| | |
|
|---|
| | | <table class="table">
|
|---|
| | | <thead>
|
|---|
| | | <tr><th>parameter</th><th>value</th><th>description</th></tr>
|
|---|
| | | </thead>
|
|---|
| | | <tbody>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.server</th><td>ldap://localhost:389</td>
|
|---|
| | | <td>Tells Gitblit to connect to the LDAP server on localhost port 389. The URL Must be of form ldap(s)://<server>:<port> with port being optional (389 for ldap, 636 for ldaps).</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.username</th><td>cn=Directory Manager</td>
|
|---|
| | | <td>The credentials that will log into the LDAP server</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.password</th><td>password</td>
|
|---|
| | | <td>The credentials that will log into the LDAP server</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.backingUserService</th><td>users.conf</td>
|
|---|
| | | <td>Where to store all information that is used by Gitblit. All information will be synced here upon user login.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.maintainTeams</th><td>true</td>
|
|---|
| | | <td>Are team memberships maintained in LDAP (<em>true</em>) or manually in Gitblit (<em>false</em>).</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.accountBase</th><td>OU=Users,OU=UserControl,OU=MyOrganization,DC=MyDomain</td>
|
|---|
| | | <td>What is the root node for all users in this LDAP system. Subtree searches will start from this node.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.accountPattern</th><td>(&(objectClass=person)(sAMAccountName=${username}))</td><td>The LDAP search filter that will match a particular user in LDAP. ${username} will be replaced with whatever the user enters as their username in the Gitblit login panel.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.groupBase</th><td>OU=Groups,OU=UserControl,OU=MyOrganization,DC=MyDomain</td>
|
|---|
| | | <td>What is the root node for all teams in this LDAP system. Subtree searches will start from this node.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.groupMemberPattern</th><td>(&(objectClass=group)(member=${dn}))</td><td>The LDAP search filter that will match all teams for the authenticating user. ${username} will be replaced with whatever the user enters as their username in the Gitblit login panel. Anything else in ${} will be replaced by Attributes from the User node.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <th>realm.ldap.admins</th><td>@Git_Admins</td><td>A space-delimited list of usernames and/or teams that indicate admin status in Gitblit. Teams are referenced with a leading <em>@</em> character.</td>
|
|---|
| | | </tr>
|
|---|
| | | </tbody>
|
|---|
| | | </table>
|
|---|
| | |
|
|---|
| | | #### LDAP In-Memory Server
|
|---|
| | |
|
|---|
| | | You can start Gitblit GO with an in-memory LDAP server by specifying the *--ldapLdifFile* command-line argument. The LDAP server will listen on localhost of the port specified in *realm.ldap.url* of `gitblit.properties`. Additionally, a root user record is automatically created for *realm.ldap.username* and *realm.ldap.password*. Please note that the ldaps:// protocol is not supported for the in-memory server.
|
|---|
| | |
|
|---|
| | | ### Custom Authentication
|
|---|
| | | This is the simplest choice where you implement custom authentication and delegate all other standard user and team operations to one of Gitblit's user service implementations. This choice insulates your customization from changes in User and Team model classes and additional API that may be added to IUserService.
|
|---|
| | |
|
|---|
| | | Please subclass [com.gitblit.GitblitUserService](https://github.com/gitblit/gitblit/blob/master/src/com/gitblit/GitblitUserService.java) and override the *setup()* and *authenticate()* methods.
|
|---|
| | |
|---|
| | |
|
|---|
| | | Your subclass must be on Gitblit's classpath and must have a public default constructor.
|
|---|
| | |
|
|---|
| | | ### Customize Everything
|
|---|
| | | ### Custom Everything
|
|---|
| | | Instead of maintaining a `users.conf` or `users.properties` file, you may want to integrate Gitblit into an existing environment.
|
|---|
| | |
|
|---|
| | | You may use your own custom *com.gitblit.IUserService* implementation by specifying its fully qualified classname in the *realm.userService* setting.
|
|---|
| | |
|---|
| | |
|
|---|
| | | ### How do I use it?
|
|---|
| | |
|
|---|
| | | Lucene indexing is an opt-in feature which means that no repositories are automatically indexed. |
|---|
| | | First you must ensure that *web.allowLuceneIndexing* is set *true* in `gitblit.properties` or `web.xml`. Then you must understand that Lucene indexing is an opt-in feature which means that no repositories are automatically indexed. |
|---|
| | | Like anything else, this design has pros and cons.
|
|---|
| | |
|
|---|
| | | #### Pros
|
|---|
| | | 1. no wasted cycles on repositories you will never search
|
|---|
| | | 1. no wasted cycles indexing repositories you will never search
|
|---|
| | | 2. you specify exactly what branches are indexed; experimental/dead/personal branches can be ignored
|
|---|
| | |
|
|---|
| | | #### Cons
|
|---|
| | | 1. you have to opt-in a repository _after_ it is created and has some commits
|
|---|
| | | 2. you specify exactly what branches are indexed
|
|---|
| | | 1. you specify exactly what branches are indexed
|
|---|
| | |
|
|---|
| | | #### I have 300 repositories and you want me to specify indexed branches on each one??
|
|---|
| | |
|
|---|
| | | Yeah, I agree that is inconvenient.
|
|---|
| | |
|
|---|
| | | If you are using Gitblit GO there is a utility script `add-indexed-branch.cmd` which allows you to specify an indexed branch for many repositories in one step.
|
|---|
| | |
|
|---|
| | | If you are using Gitblit WAR then, at present, you are out of luck unless you write your own script to traverse your repositories and use native Git to manipulate each repository config.
|
|---|
| | |
|
|---|
| | | git config --add gitblit.indexBranch "default"
|
|---|
| | | git config --add gitblit.indexBranch "refs/heads/master"
|
|---|
| | |
|
|---|
| | | #### Indexing Branches
|
|---|
| | | You may specify which branches should be indexed per-repository in the *Edit Repository* page. New/empty repositories may only specify the *default* branch which will resolve to whatever commit HEAD points to or the most recently updated branch if HEAD is unresolvable.
|
|---|
| | |
|
|---|
| | | Indexes are built and incrementally updated on a 2 minute cycle so you may have to wait a few minutes before your index is built or before your latest pushes get indexed.
|
|---|
| | |
|
|---|
| | | **NOTE:** |
|---|
| | | After specifying branches, only the content from those branches can be searched via Gitblit. Gitblit will automatically redirect any queries entered on a repository's search box to the Lucene search page. Repositories that do not specify any indexed branches will use the traditional commit-traversal search.
|
|---|
| | |
|
|---|
| | | #### Adequate Heap
|
|---|
| | |
|
|---|
| | | The initial indexing of an existing repository can potentially exhaust the memory allocated to your Java instance and may throw OutOfMemory exceptions. Be sure to provide your Gitblit server adequate heap space to index your repositories. The heap is set using the *-Xmx* JVM parameter in your Gitblit launch command (e.g. -Xmx1024M).
|
|---|
| | |
|
|---|
| | | #### Why does Gitblit check every 2 mins for repository/branch changes?
|
|---|
| | |
|
|---|
| | | Gitblit has to balance its design as a complete, integrated Git server and its utility as a repository viewer in an existing Git setup.
|
|---|
| | |
|
|---|
| | | Gitblit could build indexes immediately on *edit repository* or on *receiving pushes*, but that design would not work if someone is pushing via ssh://, git://, or file:// (i.e. not pushing to Gitblit http(s)://). For this reason Gitblit has a polling mechanism to check for ref changes every 2 mins. This design works well for all use cases, aside from adding a little lag in updating the index.
|
|---|
| | |
|
|---|
| | | #### Indexing Branches
|
|---|
| | | You may specify which branches should be indexed per-repository in the *Edit Repository* page. New/empty repositories can not pre-specify indexed branches; you can only specify indexed branches for a repository with commits. Indexes are built and incrementally updated on a 2 minute cycle so you may have to wait a few minutes before your index is built or before your latest pushes get indexed.
|
|---|
| | |
|
|---|
| | | **NOTE:** |
|---|
| | | After specifying branches, only the content from those branches can be searched via Gitblit. Gitblit will automatically redirect any queries entered on a repository's search box to the Lucene search page. Repositories that do not specify any indexed branches will use the traditional commit-traversal search.
|
|---|
| | |
|
|---|
| | | ## Client Setup and Configuration
|
|---|
| | | ### Https with Self-Signed Certificates
|
|---|
| | |
|---|
| | | <pre>https://yourserver/git/your/repository</pre>
|
|---|
| | | - **Command-line Git**
|
|---|
| | | My testing indicates that your username must be embedded in the url. YMMV.
|
|---|
| | | <pre>https://username@yourserver/git/your/repository</pre> |
|---|
| | | <pre>https://username@yourserver/git/your/repository</pre>
|
|---|
| | |
|
|---|
