Delete the test user account as part of cleanup.

James Moger

2011-10-02 5c1ae2385f9e6c0c2050e5b0cb505d25bdbe27e0

 docs/01_setup.mkd

@@ -20,18 +20,19 @@
Open `gitblit.properties` in your favorite text editor and make sure to review and set:

    - *git.repositoryFolder* (path may be relative or absolute)

    - *server.tempFolder* (path may be relative or absolute)

    - *server.httpPort* and *server.httpsPort*

    - *server.httpBindInterface* and *server.httpsBindInterface*<br/>

    **https** is strongly recommended because passwords are insecurely transmitted form your browser/git client using Basic authentication!     
    **https** is strongly recommended because passwords are insecurely transmitted form your browser/git client using Basic authentication!

3. Execute `gitblit.cmd` or `java -jar gitblit.jar` from a command-line

4. Wait a minute or two while all dependencies are downloaded and your self-signed *localhost* certificate is generated.<br/>Please see the section titled **Creating your own Self-Signed Certificate** to generate a certificate for *your hostname*.

5. Open your browser to <http://localhost> or <https://localhost> depending on your chosen configuration.

5. Open your browser to <http://localhost:8080> or <https://localhost:8443> depending on your chosen configuration.

6. Click the *Login* link and enter the default administrator credentials: **admin / admin**<br/>

    **NOTE:** Make sure to change the administrator username and/or password!! 



### Creating your own Self-Signed Certificate

Gitblit GO automatically generates an ssl certificate for you that is bound to *localhost*.



Remote Eclipse/EGit/JGit clients (<= 1.0.0) will fail to communicate using this certificate because JGit always verifies the hostname of the certificate, regardless of the *http.sslVerify=false* client-side setting.

Remote Eclipse/EGit/JGit clients (<= 1.1.0) will fail to communicate using this certificate because JGit always verifies the hostname of the certificate, regardless of the *http.sslVerify=false* client-side setting.



The EGit failure message is something like:



@@ -129,6 +130,9 @@
       accessRestriction = clone

       isFrozen = false

       showReadme = false

       federationStrategy = FEDERATE_THIS

       isFederated = false

       federationSets = 
       

#### Repository Names

Repository names must be unique and are CASE-SENSITIVE ON CASE-SENSITIVE FILESYSTEMS.  The name must be composed of letters, digits, or `/ _ - .`<br/>

@@ -155,7 +159,7 @@
User passwords are CASE-SENSITIVE and may be *plain* or *md5* formatted (see `gitblit.properties` -> *realm.passwordStorage*).



#### User Roles

There is only one actual *role* in Gitblit and that is *#admin* which grants administrative powers to that user.  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.

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

Instead of maintaining a `users.properties` file, you may want to integrate Gitblit into an existing environment.

@@ -164,6 +168,148 @@


Your user service class must be on Gitblit's classpath and must have a public default constructor. 



%BEGINCODE%

public interface IUserService {



   /**

    * Setup the user service.

    * 
    * @param settings

    * @since 0.6.1

    */

   @Override

   public void setup(IStoredSettings settings) {

   }

	
   /**

    * Does the user service support cookie authentication?

    * 
    * @return true or false

    */

   boolean supportsCookies();



   /**

    * Returns the cookie value for the specified user.

    * 
    * @param model

    * @return cookie value

    */

   char[] getCookie(UserModel model);



   /**

    * Authenticate a user based on their cookie.

    * 
    * @param cookie

    * @return a user object or null

    */

   UserModel authenticate(char[] cookie);



   /**

    * Authenticate a user based on a username and password.

    * 
    * @param username

    * @param password

    * @return a user object or null

    */

   UserModel authenticate(String username, char[] password);



   /**

    * Retrieve the user object for the specified username.

    * 
    * @param username

    * @return a user object or null

    */

   UserModel getUserModel(String username);



   /**

    * Updates/writes a complete user object.

    * 
    * @param model

    * @return true if update is successful

    */

   boolean updateUserModel(UserModel model);



   /**

    * Adds/updates a user object keyed by username. This method allows for

    * renaming a user.

    * 
    * @param username

    *            the old username

    * @param model

    *            the user object to use for username

    * @return true if update is successful

    */

   boolean updateUserModel(String username, UserModel model);



   /**

    * Deletes the user object from the user service.

    * 
    * @param model

    * @return true if successful

    */

   boolean deleteUserModel(UserModel model);



   /**

    * Delete the user object with the specified username

    * 
    * @param username

    * @return true if successful

    */

   boolean deleteUser(String username);



   /**

    * Returns the list of all users available to the login service.

    * 
    * @return list of all usernames

    */

   List<String> getAllUsernames();



   /**

    * Returns the list of all users who are allowed to bypass the access

    * restriction placed on the specified repository.

    * 
    * @param role

    *            the repository name

    * @return list of all usernames that can bypass the access restriction

    */

   List<String> getUsernamesForRepositoryRole(String role);



   /**

    * Sets the list of all uses who are allowed to bypass the access

    * restriction placed on the specified repository.

    * 
    * @param role

    *            the repository name

    * @param usernames

    * @return true if successful

    */

   boolean setUsernamesForRepositoryRole(String role, List<String> usernames);



   /**

    * Renames a repository role.

    * 
    * @param oldRole

    * @param newRole

    * @return true if successful

    */

   boolean renameRepositoryRole(String oldRole, String newRole);



   /**

    * Removes a repository role from all users.

    * 
    * @param role

    * @return true if successful

    */

   boolean deleteRepositoryRole(String role);



   /**

    * @See java.lang.Object.toString();

    * @return string representation of the login service

    */

   String toString();

}

%ENDCODE%



## Client Setup and Configuration

### Https with Self-Signed Certificates

You must tell Git/JGit not to verify the self-signed certificate in order to perform any remote Git operations.

@@ -171,7 +317,7 @@
**NOTE:**<br/>

The default self-signed certificate generated by Gitlbit GO is bound to *localhost*.<br/>

If you are using Eclipse/EGit/JGit clients, you will have to generate your own certificate that specifies the exact hostname used in your clone/push url.<br/>

You must do this because Eclipse/EGit/JGit (<= 1.0.0) always verifies certificate hostnames, regardless of the *http.sslVerify=false* client-side setting. 
You must do this because Eclipse/EGit/JGit (<= 1.1.0) always verifies certificate hostnames, regardless of the *http.sslVerify=false* client-side setting. 
 

- Eclipse/EGit/JGit

    1. Window->Preferences->Team->Git->Configuration