diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/01_setup.mkd | 28 | ||||
| -rw-r--r-- | docs/04_releases.mkd | 12 |
2 files changed, 28 insertions, 12 deletions
diff --git a/docs/01_setup.mkd b/docs/01_setup.mkd index 1cc89bf2..7ea57565 100644 --- a/docs/01_setup.mkd +++ b/docs/01_setup.mkd @@ -217,6 +217,18 @@ User passwords are CASE-SENSITIVE and may be *plain*, *md5*, or *combined-md5* f 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
+
+### Choice 1: Customize Authentication Only
+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.
+Make sure to set the *serviceImpl* field in your *setup()* method.
+
+You may use your subclass by specifying its fully qualified classname in the *realm.userService* setting.
+
+Your subclass must be on Gitblit's classpath and must have a public default constructor.
+
+### Choice 2: Customize 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.
@@ -232,19 +244,21 @@ The preferred hook mechanism is Groovy. This mechanism only executes when pushi The Groovy hook mechanism allows for dynamic extension of Gitblit to execute custom tasks on receiving and processing push events. The scripts run within the context of your Gitblit instance and therefore have access to Gitblit's internals at runtime.
-### Rules & Requirements
+### Rules, Requirements, & Behaviors
1. Your Groovy scripts must be stored in the *groovy.scriptsFolder* as specified in `gitblit.properties` or `web.xml`.
2. All script files must have the *.groovy* extension. Because of this you may omit the extension when specifying the script.
3. Scripts must be explicitly specified to be executed, no scripts are *automatically* executed by name or extension.
-4. A script can be specified to run on *all repositories* by adding the script file name to *groovy.preReceiveScripts* or *groovy.postReceiveScripts* in `gitblit.properties` or `web.xml`.
+4. A script can be specified to run on *all repositories* by adding the script file name to *groovy.preReceiveScripts* or *groovy.postReceiveScripts* in `gitblit.properties` or `web.xml`. Be mindful of access retrictions and global properties like *mail.mailingLists* if specifying *sendmail* to run on all repositories.
5. Scripts may also be specified per-repository in the repository's settings.
-6. Global/shared scripts are executed first in their listed order, followed by per-repository scripts in their listed order.
-7. A script may only be defined once in a pre-receive list and once in a post-receive list.
+6. Globally specified scripts are excluded from the list of available scripts in a repository's settings
+7. Globally specified scripts are executed first, in their listed order, followed by per-repository scripts, in their listed order.
+8. A script may only be defined once in a pre-receive list and once in a post-receive list.
You may execute the same script on pre-receive and post-receive, just not multiple times within a pre-receive or post-receive event.
-8. Gitblit does not differentiate between what can be a pre-receive script and what can be a post-receive script.
-9. If a script *returns false* then the hook chain is aborted and none of the subsequent scripts will execute.
+9. Gitblit does not differentiate between what can be a pre-receive script and what can be a post-receive script.
+10. If a script *returns false* then the pre-receive or post-receive hook chain is aborted and none of the subsequent scripts will execute.
+
+Some sample scripts are included in the GO and WAR distributions to show you how you can tap into Gitblit with the provided bound variables. Additional implementation details may be specified in the header comment of these examples.
-Some sample scripts are included in the GO and WAR distributions to show you how you can tap into Gitblit with the provided bound variables. Additional implementation details may be specified in the header comment of these examples.
Hook contributions and improvements are welcome.
### Pre-Receive
diff --git a/docs/04_releases.mkd b/docs/04_releases.mkd index 1ec06411..292ff987 100644 --- a/docs/04_releases.mkd +++ b/docs/04_releases.mkd @@ -4,16 +4,18 @@ **%VERSION%** ([go](http://code.google.com/p/gitblit/downloads/detail?name=%GO%) | [war](http://code.google.com/p/gitblit/downloads/detail?name=%WAR%) | [express](http://code.google.com/p/gitblit/downloads/detail?name=%EXPRESS%) | [fedclient](http://code.google.com/p/gitblit/downloads/detail?name=%FEDCLIENT%) | [manager](http://code.google.com/p/gitblit/downloads/detail?name=%MANAGER%) | [api](http://code.google.com/p/gitblit/downloads/detail?name=%API%)) based on [%JGIT%][jgit] *released %BUILDDATE%*
- updated: Gitblit GO is now monolithic like the WAR build. (issue 30)
-Either the dependencies are downloaded on first execution OR the dependencies are bundled, either way you would need the dependencies. This change helps adoption of GO in environments without an internet connection or with a restricted connection.
+This change helps adoption of GO in environments without an internet connection or with a restricted connection.
- added: Groovy 1.8.4 and sample pre- and post- push Groovy hook scripts. Hook scripts can be set per-repository or globally for all repositories.
Unfortunately this adds another 6 MB to the 8MB Gitblit package, but it allows for a *very* powerful, flexible, platform-independent hook script mechanism.
**New:** *groovy.scriptsFolder = groovy*
**New:** *groovy.preReceiveScripts =*
**New:** *groovy.postReceiveScripts =*
-- added: New key for mailing lists. This is _currently_ used in conjunction with the example *sendemail.groovy* post-receive hook script.
+- added: New key for mailing lists. This is used in conjunction with the *sendmail.groovy* hook script.
**New:** *mail.mailingLists =*
+- added: GitblitUserService. This is a wrapper object for the built-in user service implementations. For those wanting to only implement *custom authentication* it is recommended to subclass GitblitUserService and override the appropriate methods. Going forward, this will insulate customized behavior from new IUserService API and changes in model classes.
- added: new default user service implementation: com.gitblit.ConfigUserService (users.conf)
-This user service implementation allows for serialization and deserialization of more sophisticated Gitblit User objects and will open the door for more advanced Gitblit features. For upgrading installations, a `users.conf` file will automatically be created for you from your existing `users.properties` file on your first launch of Gitblit. You will have to manually set *realm.userService=users.conf* to switch to the new user service. The original `users.properties` file and it's corresponding implementation are deprecated.
+This user service implementation allows for serialization and deserialization of more sophisticated Gitblit User objects and will open the door for more advanced Gitblit features. For upgrading installations, a `users.conf` file will automatically be created for you from your existing `users.properties` file on your first launch of Gitblit. You will have to manually set *realm.userService=users.conf* to switch to the new user service.
+The original `users.properties` file and it's corresponding implementation are **deprecated**.
**New:** *realm.userService = users.conf*
- added: Teams for specifying user-repository access in bulk
- added: Gitblit Express bundle to get started running Gitblit on RedHat's OpenShift cloud
@@ -25,9 +27,9 @@ This user service implementation allows for serialization and deserialization of **New:** *web.datestampLongFormat = EEEE, MMMM d, yyyy*
- fixed: several a bugs in FileUserService related to cleaning up old repository permissions on a rename or delete
- added: optional flash-based 1-step *copy to clipboard* of the primary repository url
-- added: javascript-based 3-step (click, ctrl+c, enter) *copy to clipboard* of the primary repository url
+- added: javascript-based 3-step (click, ctrl+c, enter) *copy to clipboard* of the primary repository url
**New:** *web.allowFlashCopyToClipboard = true*
-- improved: empty repositories now link to the *empty repository* page which gives some direction to the user for the next step in using Gitblit. This page displays the primary push/clone url of the repository and gives sample syntax for the git command-line client. (issue 31)
+- improved: empty repositories now link to a new *empty repository* page which gives some direction to the user for the next step in using Gitblit. This page displays the primary push/clone url of the repository and gives sample syntax for the git command-line client. (issue 31)
- improved: unit testing framework has been migrated to JUnit4 syntax and the test suite has been redesigned to run all unit tests, including rpc, federation, and git push/clone tests
### Older Releases
|