Page History

...

We will use the dspace.cfg as our example for input conventions used through out throughout the system. It is a basic Java properties file, where lines are either comments, starting with a '#', blank lines, or property/value pairs of the form:

...

Some property defaults are "commented out". That is, they have a "#" proceeding preceding them, and the DSpace software ignores the config property. This may cause the feature not to be enabled, or, cause a default property to be used when the software is compiled and updated.

...

Things you should know about editing dspace.cfg files.
It is important to remember that there are * two dspace.cfg files after an installation of DSpace.*

...

1. The "source" file that is found in {{\[dspace-source\]/dspace/config/dspace.cfg}}unmigrated-wiki-markup
2. The "runtime" file that is found in {{\[dspace\]/config/dspace.cfg}}
   The runtime file is supposed to be the *copy* of the source file, which is considered the master version. However, the DSpace server and command programs only look at the _runtime_ configuration file, so when you are revising your configuration values, it is tempting to _only edit the runtime file_. *DO NOT* do this. Always make the same changes to the source version of {{dspace.cfg}} in addition to the runtime file. The two files should always be identical, since the source {{dspace.cfg}} will be the basis of your next upgrade.

...

To keep the two files in synchronization, you can edit your files in {{\[dspace-source\]/dspace/config/}} and then you would run the following commands: Wiki Markup{{{*}

cd 

...

[dspace-source

...

]/dspace/target/dspace-<version>-build.dir ant update_configs

...

This will copy the source {{dspace.cfg}} (along with other configuration files) into the runtime ({{\[dspace\]/config}}) directory.

You should remember that after editing your configuration file(s), and you are done and wish to implement the changes, you will need to:

...

• Run {{{*}{_}ant \ -Dconfig=/\[dspace\]/config/dspace.cfg update{_}{*}}} if you are updating your {{dspace.cfg}} file and wish to see the changes appear. Follow the usual sequence with copying your webapps.unmigrated-wiki-markup
• If you edit _dspace.cfg_ in _\[dspace-source\]/dspace/config/_, you should then run '_ant init_configs_' in the directory _\[dspace-source\]/dspace/target/dspace-1.5.2-build.dir_ so that any changes you may have made are reflected in the configuration files of other applications, for example Apache. You may then need to restart those applications, depending on what you changed.

The dspace.cfg Configuration Properties File

...

• Server IP: _________________________________
• Host Name (Server name): _________________________________
• dspace.url: _________________________________
• Administrator's email: _________________________________
• handle prefix: _________________________________
• assetstore directory: _________________________________
• SMTP server: _________________________________

The dspace.cfg file

Below is a brief "Properties" table for the dspace.cfg file and the documented details are referenced. Please refer to those sections for the complete details of the parameter you are working with.

dspace.dir
dspace.hostname
dspace.baseUrl
dspace.url
dspace.oai.url
dspace.name

db.name
db.url
db.driver
db.username
db.password

db.schema
db.maxconnection
db.maxwait
db.maxidle
db.statementpool
db.poolname

mail.server
mail.server.username
mail.server.password
mail.server.port
mail.from.address
feedback.recipient
mail.admin
alert.recipient
registration.notify
mail.charset
mail.allowed.referrers
mail.extraproperties
mail.server.disabled

assetstore.dir
[assetstore.dir.1
assetstore.dir.2
assetstore.incoming]

srb.hosts.1
srb.port.1
srb.mcatzone.1
srb.mdasdomainname.1
srb.defaultstorageresource.1
srb.username.1
srb.password.1
srb.homedirectory.1
srb.parentdir.1

log.init.config
log.dir
useProxies

search.dir
search.max-clauses
search.analyzer
search.operator
search.maxfieldlengthsearch.index.n
search.index.1

handle.prefix
handle.dir

core.authorization.community-admin.create-subelement
core.authorization.community-admin.delete-subelement
core.authorization.community-admin.policies
core.authorization.community-admin.admin-group
core.authorization.community-admin.collection.policies
core.authorization.community-admin.collection.template-item
core.authorization.community-admin.collection.submitters
core.authorization.community-admin.collection.workflows
core.authorization.community-admin.collection.admin-group
core.authorization.community-admin.item.delete
core.authorization.community-admin.item.withdraw
core.authorization.community-admin.item.reinstatiate
core.authorization.community-admin.item.policies
core.authorization.community-admin.item.create-bitstream
core.authorization.community-admin.item.delete-bitstream
core.authorization.community-admin.item-admin.cc-license
core.authorization.collection-admin.policies
core.authorization.collection-admin.template-item
core.authorization.collection-admin.submitters
core.authorization.collection-admin.workflows
core.authorization.collection-admin.admin-group
core.authorization.collection-admin.item.delete
core.authorization.collection-admin.item.withdraw
core.authorization.collection-admin.item.reinstatiate
core.authorization.collection-admin.item.policies
core.authorization.collection-admin.item.create-bitstream
core.authorization.collection-admin.item.delete-bitstream
core.authorization.collection-admin.item-admin.cc-license
core.authorization.item-admin.policies
core.authorization.item-admin.create-bitstream
core.authorization.item-admin.delete-bitstream
core.authorization.item-admin.cc-license

plugin.sequence.org.dspace.authenticate.AuthenticationMethod

authentication.shib.email-header
authentication.shib.firstname-header
authentication.shib.lastname-header
authentication.shib.email-use-tomcat-remote-user
authentication.shib.autoregister
authentication.shib.role-header
authentication.shib.default-roles
authentication.shib.role.Senior\ Researcher
authentication.shib.role.Librarian

authentication.password.domain.valid
    password.login.specialgroup

authentication.x509.keystore.path
authentication.x509.keystore.password
authentication.x509.keystore.cert
authentication.x509.keystore.autoregister
authentication.x509.chooser.title.key
authentication.x509.chooser.uri

ldap.enable
ldap.provider_url
ldap.id_field
ldap.object_context
ldap.search_context
ldap.email_field
ldap.surname_field
ldap.givenname_field
ldap.phone_field
webui.ldap.autoregister
ldap.login.specialgroup

ldap.search_scope
ldap.search.user
ldap.netid_email_domain

harvest.includerestricted.rss
harvest.includerestricted.oai
harvest.includerestricted.subscription

http.proxy.host
http.proxy.port

filter.plugins
plugin.named.org.dspace.app.mediafilter.FormatFilter
   filter.org.dspace.app.mediafilter.PDFFilter.inputFormats
   filter.org.dspace.app.mediafilter.HTMLFilter.inputFormats
   filter.org.dspace.app.mediafilter.WordFilter.inputFormats
   filter.org.dspace.app.mediafilter.JPEGFilter.inputFormats
   filter.org.dspace.app.mediafilter.BrandedPreviewJPEGFilter.inputFormats

pdffilter.largepdfsdffilter.skiponmemoryexception

crosswalk.mods.properties.MODS
crosswalk.mods.properties.mods
crosswalk.submission.MODS.stylesheet

crosswalk.qdc.namespace.QDC.dc
crosswalk.qdc.namespace.QDC.dcterms
crosswalk.qdc.schemaLocation.QDC
crosswalk.qdc.properties.QDC
mets.submission.crosswalk.DC
mets.submission.preserveManifest
mets.submission.useCollectionTemplate

plugin.named.org.dspace.content.crosswalk.IngestionCrosswalk
plugin.selfnamed.org.dspace.content.crosswalk.IngestionCrosswalk
plugin.named.org.dspace.content.crosswalk.DisseminationCrosswalk
plugin.selfnamed.org.dspace.content.crosswalk.DisseminationCrosswalk

plugin.named.org.dspace.content.packager.PackageDisseminator
plugin.named.org.dspace.content.packager.PackageIngester

event.dispatcher.default.class
event.dispatcher.default.consumers
event.dispatcher.noindex.class
event.dispatcher.noindex.consumers
event.consumer.search.class
event.consumer.search.filters
event.consumer.browse.class
event.consumer.browse.filters
event.consumer.eperson.class
event.consumer.eperson.filters
event.consumer.harvester.class
event.consumer.harvester.filters
event.consumer.test.class
event.consumer.test.filters
testConsumer.verbose

embargo.field.terms
embargo.field.lift
embargo.field.open
plugin.single.org.dspace.embargo.EmbargoSetter
plugin.single.org.dspace.embargo.EmbargoLifter

plugin.single.org.dspace.checker.BitsreamDispatcher
checker.retention.default
checker.retention.CHECKSUM-MATCH

org.dspace.app.itemexport.work.dir
org.dspace.app.itemexport.download.dir
org.dspace.app.itemexport.life.span.hours
org.dspace.app.itemexport.max.size

eperson.subscription.onlynew

bulkedit.valueseparator
bulkedit.fieldseparator
bulkedit.gui-item-limit
bulkedit.ignore-on-export

metadata.hide.dc.description.provenance

webui.submit.blocktheses
webui.submit.upload.required

webui.submit.enable-cc
webui.submit.cc-jurisdiction

webui.browse.thumbnail.show
webui.browse.thumbnail.max.height
webui.browse.thumbnail.max.width
webui.item.thumbnail.show
webui.browse.thumbnail.linkbehaviour
thumbnail.maxwidth
thumbnail.maxheight

webui.preview.enabled
webui.preview.maxwidth
webui.preview.maxheight
webui.preview.brand
webui.preview.brand.abbrev
webui.preview.brand.height
webui.preview.brand.font
webui.preview.brank.fontpoint
webui.preview.dc

webui.strengths.show
webui.strengths.cache

webui.browse.value_columns.max
webui.browse.sort_columns.max
webui.browse.value_columns.omission_mark
plugin.named.org.dspace.sort.OrderFormatDelegate

webui.browse.author-field
webui.browse.author-limit

recent.submission.sort-option
recent.submissions.count
plugin.sequence.org.dspace.plugin.CommunityHomeProcessor
plugin.sequence.org.dspace.plugin.CollectionHomeProcessor

webui.feed.enable
webui.feed.items
webui.feed.cache.size
webui.cache.age
webui.feed.formats
webui.feed.localresolve
webui.feed.item.title
webui.feed.item.date
webui.feed.item.description
webui.feed.item.author
webui.feed.item.dc.creator
webui.feed.item.dc.date
webui.feed.item.dc.description
webui.feed.logo.url

websvc.opensearch.enable
websvc.opensearch.uicontext
websvc.opensearch.svccontext
websvc.opensearch.autolink
websvc.opensearch.validity
websvc.opensearch.shortname
websvc.opensearch.longname
websvc.opensearch.description
websvc.opensearch.faviconurl
websvc.opensearch.samplequery
websvc.opensearch.tags
websvc.opensearch.formats

webui.content_disposition_threshold
xmlui.content_disposition_threshold

webui.html.max-depth-guess
xmlui.html.max-depth-guess

sitemap.dir
sitemap.engineurls

plugin.named.org.dspace.content.authority.ChoiceAuthority
plugin.selfnamed.org.dspace.content.authority.ChoiceAuthority
lcname.url
sherpa.romeo.url
authority.minconfidence
xmlui.lookup.select.size

upload.temp.dir
upload.max

webui.licence_bundle.show
webui.itemdisplay.default
webui.resolver.1.urn
webui.resolver.1.baseurl
webui.resolver.2.urn
webui.resolver.2.baseurl
plugin.single.org.dspace.app.webui.util.StyleSelection
webui.itemdisplay.thesis.collections
webui.itemdisplay.metadata-style
webui.itemlist.columns
webui.itemlist.widths
webui.itemlist.browse.<<index name>.sort.<sort name>.columns
webui.itemlist.sort<sort name>.columns
webui.itemlist.browse.<browse name>.columns
webui.itemlist.<sort or index name>.columns
webui.itemlist.dateaccessioned.columns
webui.itemlist.dateaccessioned.widths
webui.itemlist.tablewidth

webui.suggest.enable
webui.suggest.loggedinusers.only

xmlui.supported.locales
xmlui.force.ssl
xmlui.user.registration
xmlui.user.editmetadata
xmlui.user.assumelogin
xmlui.user.logindirect
xmlui.theme.allowoverrides
xmlui.bundle.upload
xmlui.community-list.render.full
xmlui.community-list.cache
xmlui.bitstream.mods
xmlui.bitstream.mets
xmlui.google.analytics.key
xmlui.controlpanel.activity.max
xmlui.controlpanel.activity.ipheader

oai.didl.maxresponse
oai.mets.hide-provenance

mets.submission.crosswalk.EPDCX
crosswalk.submission.SWORD.stylesheet
sword.deposit.url
sword.servicedocument.url
sword.media-link.url
sword.generator.url
sword.updated.field
sword.slug.field
sword.accept-packaging.METSDSpaceSIP.identifier
sword.accept-packaging.METSDSpaceSIP.q
sword.accepts
sword.expose-items
sword.expose-communities
sword.max-upload-size
sword.keep-original-package
sword.bundle.name
sword.identify-version
sword.on-behalf-of.enable

harvester.oai.metadataformats.dc
harvester.oai.metadataformats.qdc
harvester.oai.metadataformats.dim
harvester.autoStart
harvester.timePadding
harvester.harvestFrequency
harvester.minHeartbeat
harvester.maxHeartbeat
harvester.threadTimeout
harvester.unknownField
harvester.unknownSchema
ore.authoritative.source
harvester.acceptedHandleServer
harvester.rejectedHandlePrefix

solr.log.server
solr.dbfilesolr.resolver.timeout
statistics.item.authorization.adminsolr.statistics.logBots
solr.statistics.query.filter.spiderIP
solr.statistics.query.filter.isBot
solr.spiderips.urls

...

...

Wording of E-mail Messages

...

Sometimes DSpace automatically sends e-mail messages to users, for example, to inform them of a new work flow task, or as a subscription e-mail alert. The wording of emails can be changed by editing the relevant file in {{\[dspace\]/config/emails}} . Each file is commented. Be careful to keep the right number 'placeholders' (e.g._\{2\}_).

Note: You should replace the contact-information "dspace-help@myu.edu or call us at xxx-555-xxxx" with your own contact details in:
config/emails/change_password
config/emails/register

...

DSpace supports two distinct options for storing your repository bitstreams (uploaded files). The files are not stored in the database in which Metadata, user information, ... are stored. An assetstore is a directory on your server, on which the bitstreams are stored and consulted afterwards. The usage of different assetstore directories is the default "technique" in DSpace. The parameters below define which assetstores are present, and which one should be used for newly incoming items. As an alternative, DSpace can also use SRB (Storage Resource Brokerage) as an alternative. See Section 5.2.6 SRB File Storage for details regarding SRB.

Property:	assetstore.dir
Example Value:	assetstore.dir = ${dspace.dir}/assetstore
Informational Note:	This is Asset (bitstream) store number 0 (Zero). You need not place your assetstore under the /dspace directory, but may want to place it on a different logical volume on the server that DSpace resides. So, you might have something like this: _ assetstore.dir = /storevgm/assestore_ .
Property:	Code Block assetstore.dir.1 assetstore.dir.2
Example Value:	Code Block assetstore.dir.1 = /second/assetstore assetstore.dir.2 = /third/assetstore
Informational Note:	This property specifies extra asset stores like the one above, counting from one (1) upwards. This property is commented out (#) until it is needed.
Property:	assetstore.incoming
Example Value:	assetstore.incoming = 1
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="358ec7b4-83e2-4aeb-8c78-497114b89845"><ac:plain-text-body><![CDATA[	Informational Note:	Informational Note: Specify the number of the store to use for new bitstreams with this property. The default is 0 [(zero] ) which corresponds to the 'assestore.dir' above. As the asset store number is stored in the item metadata (in the database), always keep the assetstore numbering consistent and don't change the asset store number in the item metadata.	]]></ac:plain-text-body></ac:structured-macro>

Info
title Be Careful
In the examples above, you can see that your storage does not have to be under the /dspace directory. For the default installation it needs to reside on the same server (unless you plan to configure SRB (cf. see below)). So, if you added storage space to your server, and it has a different logical volume/name/directory, you could have the following as an example:

...

• a local file system directory (native DSpace)
• a set of SRB account parameters (host, port, zone, domain, username, password, home directory, and resource
  Should the there be any conflict, like '2' referring to a local directory and to a set of SRB parameters, the program will select the local directory.

...

Logging Configuration

log.init.config = ${dspace.dir}/config/log4j.properties
log.init.config = ${dspace.dir}/config/log4j-console.properties

...

For example, the following entries appear in the default DSpace installation:

...

...

search.index.1

...

=

...

author:dc.contributor.*

...

search.index.2

...

=

...

author:dc.creator.*

...

search.index.3

...

=

...

title:dc.title.*

...

search.index.4

...

=

...

keyword:dc.subject.*

...

search.index.5

...

=

...

abstract:dc.description.abstract

...

search.index.6

...

=

...

author:dc.description.statementofresponsibility

...

search.index.7

...

=

...

series:dc.relation.ispartofseries

...

search.index.8

...

=

...

abstract:dc.description.tableofcontents

...

search.index.9

...

=

...

mime:dc.format.mimetype

...

search.index.10

...

=

...

sponsor:dc.description.sponsorship

...

search.index.11

...

=

...

id:dc.identifier.*

...

search.index.11

...

=

...

language:dc.language.iso

...

The format of each entry is search.index.<id> = <search label> : <schema> . <metadata field> where:

In the example above, search.index.1 and search.index.2 and search.index.3 are configured as the author search field. The author index is created by Lucene indexing all dc.contributor.*,dc.creator.* and description.statementofresponsibility metadata fields.unmigrated-wiki-markup

After changing the configuration run _/\[dspace\]/bin/dspace index-init_ to regenerate the indexes.

While the indexes are created, this only affects the search results and has no effect on the search components of the user interface. One will need to customize the user interface to reflect the changes, for example, to add the a new search category to the Advanced Search.

In the above examples, notice the asterisk (*). The metadata field (at least for Dublin Core) is made up of the "element" and the "qualifier". The asterisk is used as the "wildcard". So, for example, keyword.dc.subject.* will index all subjects regardless if the term resides in a qualified field. (subject versus subject.lcsh). One could customize the search and only index LCSH (Library of Congress Subject Headings) with the following entry keyword:dc.subject.lcsh_ instead _ of keyword:dc.subject.*

Authority Control Note:

Although DSIndexer automatically builds a separate index for the authority keys of any index that contains authority-controlled metadata fields, the "Advanced Search" UIs does not allow direct access to it. Perhaps it will be added in the future. Fortunately, the OpenSearch API lets you submit a query directly to the Lucene search engine, and this may include the authority-controlled indexes.

...

The CNRI Handle system is a 3rd party service for maintaining persistent URL's. For a nominal fee, you can register a handle prefix for your repository. As a result, your repository items will be also available under the links http://handle.net/<<handle prefix>>/<<item id>>. As the base url of your repository might change or evolve, the persistent handle.net URL's secure the consistency of links to your repository items. For complete information regarding the Handle server, the user should consult Section 3.4.4.. The Handle Server section of Installing DSpace.

For complete information regarding the Handle server, the user should consult 3.For complete information regarding the Handle server, the user should consult 3.3.4. The Handle Server section of Installing DSpace.

...

core.authorization.collection-admin.policies
core.authorization.collection-admin.template-item
core.authorization.collection-admin.submitters
core.authorization.collection-admin.workflows
core.authorization.collection-admin.admin-group

core.authorization.collection-admin.item.delete
core.authorization.collection-admin.item.withdraw
core.authorization.collection-admin.item.reinstatiate
core.authorization.collection-admin.item.policies

core.authorization.collection-admin.item.create-bitstream
core.authorization.collection-admin.item.delete-bitstream
core.authorization.collection-admin.item-admin.cc-license

core.authorization.item-admin.create-bitstream
core.authorization.item-admin.delete-bitstream
core.authorization.item-admin.cc-license

...

(formally Custom Authentication)

Since many institutions and organizations have existing authentication systems, DSpace has been designed to allow these to be easily integrated into an existing authentication infrastructure. It keeps a series, or "stack", of authentication methods, so each one can be tried in turn. This makes it easy to add new authentication methods or rearrange the order without changing any existing code. You can also share authentication code with other sites.

...

plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \

...

 org.dspace.authenticate.PasswordAuthentication

The configuration property plugin.sequence.org.dspace.authenticate.AuthenticationMethod defines the authentication stack. It is a comma-separated list of class names. Each of these classes implements a different authentication method, or way of determining the identity of the user. They are invoked in the order specified until one succeeds.

An authentication method is a class that implements the interface org.dspace.authenticate.AuthenticationMethod. It authenticates a user by evaluating the credentials (e.g. username and password) he or she presents and checking that they are valid.

...

1. A request is received from an end-user's browser that, if fulfilled, would lead to an action requiring authorization taking place.
2. If the end-user is already authenticated:
   • If the end-user is allowed to perform the action, the action proceeds
   • If the end-user is NOT allowed to perform the action, an authorization error is displayed.
   • If the end-user is NOT authenticated, i.e. is accessing DSpace anonymously:
3. The parameters etc. of the request are stored.
4. The Web UI's startAuthentication method is invoked.
5. First it tries all the authentication methods which do implicit authentication (i.e. they work with just the information already in the Web request, such as an X.509 client certificate). If one of these succeeds, it proceeds from Step 2 above.
6. If none of the implicit methods succeed, the UI responds by putting up a "login" page to collect credentials for one of the explicit authentication methods in the stack. The servlet processing that page then gives the proffered credentials to each authentication method in turn until one succeeds, at which point it retries the original operation from Step 2 above.
   Please see the source files AuthenticationManager.java and AuthenticationMethod.java for more details about this mechanism.

...

1. By explicitly specifying to the user which attribute (header) carries the email address.
2. By turning on the user-email-using-tomcat=true which means the software will attempt to acquire the user's email from Tomcat.
   The first option takes Precedence when specified. both options can be enabled to allow for fallback.

   Property:	authentication.shib.email-header
   Example Value:	authentication.shib.email-header = MAIL
   Informational Note:	The option specifies that the email comes from the mentioned header. This value is CASE-Sensitive.
   Property:	authentication.shib.firstname-header
   Example Value:	authentication.shib.firstname-header = SHIB-EP-GIVENNAME
   Informational Note:	Optional. Specify the header that carries the user's first name. This is going to be used for the creation of new-user.
   Property:	authentication.shib.lastname-header
   Example Value:	authentication.shib.lastname-header = SHIB-EP-SURNAME
   Informational Note:	Optional. Specify the header that carries user's last name. This is used for creation of new user.
   Property:	authentication.shib.email-use-tomcat-remote-user
   Example Value:	authentication.shib.email-use-tomcat-remote-user = true
   Informational Note:	This option forces the software to acquire the email from Tomcat.
   Property:	authentication.shib.autoregister
   Example Value:	authentication.shib.autoregister = true
   Informational Note:	Option will allow new users to be registered automatically if the IdP provides sufficient information (and the user does not exist in DSpace).
   Property:	Code Block authentication.shib.role-header authentication.shib-role.header.ignore-scope
   Example Value:	Code Block authentication.shib.role-header = Shib-EP-ScopedAffiliation authentication.shib-role.header.ignore-scope = true or Code Block authentication.shib.role-header = Shib-EP-UnscopedAffiliation authentication.shib-role.header.ignore-scope = false
   Informational Note:	These two options specify which attribute that is responsible for providing user's roles to DSpace and unscope the attributes if needed. When not specified, it is defaulted to 'Shib-EP-UnscopedAffiliation', and ignore-scope is defaulted to 'false'. The value is specified in AAP.xml (Shib 1.3.x) or attribute-filter.xml (Shib 2.x). The value is CASE-Sensitive. The values provided in this header are separated by semi-colon or comma. If your sp service provider (SP) only provides scoped role header, you need to set authentication.shib.role-header.ignore-Scope as 'true'. For example if you only get Shib-EP-ScopedAffiliation instead of Shib-EP-ScopedAffiliation, you name to make your settings as in the example value above.
   Property:	authentication.shib.default-roles
   Example Value:	authentication.shib.default-roles = Staff, Walk-ins
   Informational Note:	When user is fully authN or IdP but would not like to release his/her roles to DSpace (for privacy reasons?), what should the default roles be given to such user. The values are separated by semi-colon or comma.
   Property:	Code Block authentication.shib.role.Senior\ Researcher authentication.shib.role.Librarian
   Example Value:	Code Block authentication.shib.role.Senior\ Researcher = Researcher, Staff authentication.shib.role.Librarian = Administrator
   Informational Note:	The following mappings specify role mapping between IdP and Dspace. The left side of the entry is IdP's role (prefixed with 'authentication.shib.role.') which will be mapped to the right entry from DSpace. DSpace's group as indicated on the right entry has to EXIST in DSpace, otherwise user will be identified as 'anonymous'. Multiple values on the right entry should be separated by comma. The values are CASE-Sensitive. Heuristic one-to-one mapping will be done when the IdP groups entry are not listed below (i.e. if 'X' group in IdP is not specified here, then it will be mapped to 'X' group in DSpace if it exists, otherwise it will be mapped to simply 'anonymous'). Given sufficient demand, future release could support regex for the mapping special characters need to be escaped by '\'

Authentication by Password

The default method org.dspace.authenticate.PasswordAuthentication has the following properties:

• Use of inbuilt e-mail address/password-based log-in. This is achieved by forwarding a request that is attempting an action requiring authorization to the password log-in servlet, /password-login. The password log-in servlet (org.dspace.app.webui.servlet.PasswordServlet) contains code that will resume the original request if authentication is successful, as per step 3. described above.
• Users can register themselves (i.e. add themselves as e-people without needing approval from the administrators), and can set their own passwords when they do this
• Users are not members of any special (dynamic) e-person groups
• You can restrict the domains from which new users are able to register. To enable this feature, uncomment the following line from dspace.cfg: authentication.password.domain.valid = example.com Example options might be '@example.com' to restrict registration to users with addresses ending in @example.com, or '@example.com, .ac.uk' to restrict registration to users with addresses ending in @example.com or with addresses in the .ac.uk domain.

...

1. See the HTTPS installation instructions to configure your Web server. If you are using HTTPS with Tomcat, note that the <Connector> tag must include the attribute clientAuth="true" so the server requests a personal Web certificate from the client.
2. Add the org.dspace.authenticate.X509Authentication plugin first to the list of stackable authentication methods in the value of the configuration key plugin.sequence.org.dspace.authenticate.AuthenticationMethod e.g.:

   Code Block
   plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \ org.dspace.authenticate.X509Authentication, \ org.dspace.authenticate.PasswordAuthentication

1. You must also configure DSpace with the same CA certificates as the web server, so it can accept and interpret the clients' certificates. It can share the same keystore file as the web server, or a separate one, or a CA certificate in a file by itself. Configure it by one of these methods, either the Java keystore

   Code Block
   authentication.x509.keystore.path = path to Java keystore file authentication.x509.keystore.password = password to access the keystore

   ...or the separate CA certificate file (in PEM or DER format):

   Code Block
   authentication.x509.ca.cert = path to certificate file for CA whose client certs to accept.

2. Choose whether to enable auto-registration: If you want users who authenticate successfully to be automatically registered as new E-Persons if they are not already, set the authentication.x509.autoregister configuration property to true. This lets you automatically accept all users with valid personal certificates. The default is false.

Example of a Custom Authentication Method

...

You can create your own custom authentication method and add it to the stack. Use the most similar existing method as a model, e.g. org.dspace.authenticate.PasswordAuthentication for an "explicit" method (with credentials entered interactively) or org.dspace.authenticate.X509Authentication for an implicit method.

Configuring IP Authentication

You can enable IP authentication by adding its method to the stack in the DSpace configuration, e.g.:

 plugin.sequence.org.dspace.authenticate.AuthenticationMethod =
                              org.dspace.authenticate.IPAuthentication 

...

You are than then able to map DSpace groups to IP 's addresses in dspace.cfg by setting _authentication.ip.GROUPNAME = iprange\[, iprange ...\], _ e.g:

 authentication.ip.MY_UNIVERSITY = 10.1.2.3, \                  # Full IP
                                   13.5, \                      # Partial IP
                                   11.3.4.5/24, \               # with CIDR
                                   12.7.8.9/255.255.128.0,      # with netmask
                                  2001:18e8::/32               # IPv6 too

Negative matches can be set by prepending the entry with a '-'. For example if you want to include all of a class B network except for users of a contained class c network, you could use: 111.222,-111.222.333.

...

You can enable LDAP authentication by adding its method to the stack in the DSpace configuration, e.g.

plugin.sequence.org.dspace.authenticate.AuthenticationMethod =
                 plugin.sequence.org.dspace.authenticate.AuthenticationMethod =
                      org.dspace.authenticate.LDAPAuthentication
                          

If LDAP is enabled in the dspace.cfg file, then new users will be able to register by entering their username and password without being sent the registration token. If users do not have a username and password, then they can still register and login with just their email address the same way they do now.

...

Hierarchical LDAP Settings. If your users are spread out across a hierarchical tree on your LDAP server, you will need to use the following stackable authentication class:

plugin.sequence.org.dspace.authenticate.AuthenticationMethod = \
       org.dspace.authenticate.LDAPHierarchicalAuthentication

You can optionally specify the search scope. If anonymous access is not enabled on your LDAP server, you will need to specify the full DN and password of a user that is allowed to bind in order to search for the users.

Restricted Item Visibility Settings

...

In large repositories, setting harvest.includerestricted.oai to false may cause performance problems as all items will need to have their authorization permissions checked, but because DSpace has not implemented resumption tokens in ListIdentifiers, ALL items will need checking whenever a ListIdentifers request is made.

...

These settings for proxy are commented out by default. Uncomment and specify both properties if proxy server is required for external http requests. Use regular host name without port number.

...

Media Filters are configured as Named Plugins, with each filter also having a separate configuration setting (in dspace.cfg) indicating which formats it can process. The default configuration is shown below.

filter.plugins = PDF Text Extractor, Html Text Extractor, \
                         Word Text Extractor, JPEG Thumbnail

Word Text Extractor, JPEG Thumbnail,\
     Branded Preview JPEG

plugin.named.org.dspace.app.mediafilter.FormatFilter = \
         org.dspace.app.mediafilter.PDFFilter = PDF Text Extractor, \
         org.dspace.app.mediafilter.HTMLFilter = HTML Text Extractor, \
         org.dspace.app.mediafilter.WordFilter = Word Text Extractor, \
         org.dspace.app.mediafilter.JPEGFilter = JPEG Thumbnail, \
         org.dspace.app.mediafilter.BrandedPreviewJPEGFilter = Branded Preview JPEG

filter.org.dspace.app.mediafilter.PDFFilter.inputFormats
filter.org.dspace.app.mediafilter.HTMLFilter.inputFormats
filter.org.dspace.app.mediafilter.WordFilter.inputFormats
filter.org.dspace.app.mediafilter.JPEGFilter.inputFormats
filter.org.dspace.app.mediafilter.BrandedPreviewJPEGFilter.inputFormats

filter.org.dspace.app.mediafilter.PDFFilter.inputFormats = Adobe PDF
filter.org.dspace.app.mediafilter.HTMLFilter.inputFormats = HTML, Text
filter.org.dspace.app.mediafilter.WordFilter.inputFormats = Microsoft Word
filter.org.dspace.app.mediafilter.JPEGFilter.inputFormats = BMP, GIF, JPEG, \
                                                            image/png
filter.org.dspace.app.mediafilter.BrandedPreviewJPEGFilter.inputFormats = BMP, \
                                                   GIF, JPEG, image/png

Names are assigned to each filter using the plugin.named.org.dspace.app.mediafilter.FormatFilter field (e.g. by default the PDFilter is named "PDF Text Extractor".

Finally, the appropriate filter.<class path>.inputFormats defines the valid input formats which each filter can be applied. These format names must match the short description field of the Bitstream Format Registry.

You can also implement more dynamic or configurable Media/Format Filters which extend SelfNamedPlugin .

Crosswalk and Packager Plugin Settings

...

The MODS crosswalk is a self-named plugin. To configure an instance of the MODS crosswalk, add a property to the DSpace configuration starting with "crosswalk.mods.properties."; the final word of the property name becomes the plugin's name. For example, a property name crosswalk.mods.properties.MODS defines a crosswalk plugin named "MODS".

The value of this property is a path to a separate properties file containing the configuration for this crosswalk. The pathname is relative to the DSpace configuration directory, i.e. the config subdirectory of the DSpace install directory. Example from the _dspace.cfg_ file:

The MODS crosswalk properties file is a list of properties describing how DSpace metadata elements are to be turned into elements of the MODS XML output document. The property name is a concatenation of the metadata schema, element name, and optionally the qualifier. For example, the contributor.author element in the native Dublin Core schema would be: dc.contributor.author. The value of the property is a line containing two segments separated by the vertical bar ("|"_): The first part is an XML fragment which is copied into the output document. The second is an XPath expression describing where in that fragment to put the value of the metadata element. For example, in this property:

dc.contributor.author = <mods:name>
							<mods:role>
								<mods:roleTerm type="text">author</mods:roleTerm>
                        	</mods:role>
                             		<mods:namePart>%s</mods:namePart>
                        </mods:name> 

Some of the examples include the string "%s" in the prototype XML where the text value is to be inserted, but don't pay any attention to it, it is an artifact that the crosswalk ignores. For example, given an author named Jack Florey, the crosswalk will insert

...

The default settings in the dspace.cfg file for submission crosswalk:

As shown above, there are three (3) parts that make up the properties "key":

     crosswalk.submissionPluginName.stylesheet =
          1        2        3               4 

...

_crosswalk_ first part of the property key._
submission_ second part of the property key.\__PluginName__ is the name of the plugin. The _path_ value is the path to the file containing the crosswalk stylesheet (relative to _/\[dspace\]/config_). Here is an example that configures a crosswalk named "LOM" using a stylesheet in _\[dspace\
PluginName is the name of the plugin. The path value is the path to the file containing the crosswalk stylesheet (relative to /[dspace]/config).
Here is an example that configures a crosswalk named "LOM" using a stylesheet in [dspace]/config/crosswalks/d-lom.xsl_:

...

...

crosswalk.submission.LOM.stylesheet

...

=

...

crosswalks/d-lom.xsl
A dissemination crosswalk can be configured by starting with the property key crosswalk.dissemination. Example:

...

...

crosswalk.dissemination.PluginName.stylesheet

...

=

...

path

...

unmigrated-wiki-markup
The _PluginName_ is the name of the plugin (!) . The _path_ value is the path to the file containing the crosswalk stylesheet (relative to _/\[dspace\]/config_).

You can make two different plugin names point to the same crosswalk, by adding two configuration entries with the same path:

     crosswalk.submission.MyFormat.stylesheet = crosswalks/myformat.xslt
     crosswalk.submission.almost_DC.stylesheet = crosswalks/myformat.xslt

The dissemination crosswalk must also be configured with an XML Namespace (including prefix and URI) and an XML schema for its output format. This is configured on additional properties in the DSpace configuration:

     crosswalk.dissemination.PluginName.namespace.Prefix = namespace-URI
     crosswalk.dissemination.PluginName.schemaLocation = schemaLocation value

For example:

     crosswalk.dissemination.qdc.namespace.dc = http://purl.org/dc/elements/1.1/
     crosswalk.dissemination.qdc.namespace.dcterms = http://purl.org/dc/terms/
     crosswalk.dissemination.qdc.schemalocation = http://purl.org/dc/elements/1.1/ \
     http://dublincore.org/schemas/xmls/qdc/2003/04/02/qualifieddc.xsd

...

where plugin is the name of the crosswalk plugin to test (e.g. "LOM"), and input-file is a file containing an XML document of metadata in the appropriate format.

Add the -l option to pass the ingestion crosswalk a list of elements instead of a whole document, as if the List form of the ingest() method had been called. This is needed to test ingesters for formats like DC that get called with lists of elements instead of a root element.

...

The QDC crosswalk is a self-named plugin. To configure an instance of the QDC crosswalk, add a property to the DSpace configuration starting with "crosswalk.qdc.properties."; the final word of the property name becomes the plugin's name. For example, a property name crosswalk.qdc.properties.QDC defines a crosswalk plugin named "QDC".

The following is from dspace.cfg file:

crosswalk.qdc.schemaLocation.QDC = http://www.purl.org/dc/terms \
      http://dublincore.org/schemas/xmls/qdc/2006/01/06/dcterms.xsd \
      http://purl.org/dc/elements/1.1 \
      http://dublincore.org/schemas/xmls/qdc/2006/01/06/dc.xsd

In the property key " Wiki MarkupIn the property key "_crosswalk.qdc.properties.QDC_" the value of this property is a path to a separate properties file containing the configuration for this crosswalk. The pathname is relative to the DSpace configuration directory __/\[dspace\]/config{_}_ . Referring back to the "Example Value" for this property key, one has \_crosswalks/qdc.properties_ which defines a crosswalk named _QDC_ whose configuration comes from the file _\[dspace\]/config/crosswalks/qdc.properties_ .

You will also need to configure the namespaces and schema location strings for the XML output generated by this crosswalk. The namespaces properties names are formatted:

crosswalk.qdc.namespace.prefix = uri

where prefix is the namespace prefix and uri is the namespace URI. See the above Property and Example Value keys as the default dspace.cfg has been configured.

The QDC crosswalk properties file is a list of properties describing how DSpace metadata elements are to be turned into elements of the Qualified DC XML output document. The property name is a concatenation of the metadata schema, element name, and optionally the qualifier. For example, the contributor.author element in the native Dublin Core schema would be: dc.contributor.author . The value of the property is an XML fragment, the element whose value will be set to the value of the metadata field in the property key.

For example, in this property:

_ dc.coverage.temporal = <dcterms:temporal />_

the generated XML in the output document would look like, e.g.:

...

...

<dcterms:temporal>Fall,

...

2005</dcterms:temporal>

Configuring Crosswalk Plugins

Ingestion crosswalk plugins are configured as named or self-named plugins for the interface org.dspace.content.crosswalk.IngestionCrosswalk. Dissemination crosswalk plugins are configured as named or self-named plugins for the interface org.dspace.content.crosswalk.DisseminationCrosswalk.

You can add names for existing crosswalks, add new plugin classes, and add new configurations for the configurable crosswalks as noted below.

...

Package ingester plugins are configured as named or self-named plugins for the interface org.dspace.content.packager.PackageIngester . Package disseminator plugins are configured as named or self-named plugins for the interface org.dspace.content.packager.PackageDisseminator .

You can add names for the existing plugins, and add new plugins, by altering these configuration properties. See the Plugin Manager architecture for more information about plugins.

...

If you are unfamiliar with the Event System in DSpace, and require additional information with terms like "Consumer" and "Dispatcher" please refer to:http://wiki.dspace.org/index.php/EventSystemPrototype

...

DSpace embargoes utilize standard metadata fields to hold both the 'terms' and the 'lift date'. Which fields you use are configurable, and no specific metadata element is dedicated or predefined for use in embargo. Rather, you specify exactly what field you want the embargo system to examine when it needs to find the terms or assign the lift date.

...

After the fields defined for terms and lift date have been assigned in dspace.cfg, and created and configured wherever they will be used, you can begin to embargo items simply by entering data (dates, if using the default setter) in the terms field. They will automatically be embargoed as they exit workflow. For the embargo to be lifted on any item, however, a new administrative procedure must be added: the 'embargo lifter' must be invoked on a regular basis. This task examines all embargoed items, and if their 'lift date' has passed, it removes the access restrictions on the item. Good practice dictates automating this procedure using cron jobs or the like, rather than manually running it. The lifter is available as a target of the 1.6 DSpace launcher: see Section 8..

Extending Embargo Functionality

The 1.6 Embargo system supplies a default 'interpreter/imposition' class (the 'Setter') as well as a 'Lifter', but they are fairly rudimentary in several aspects.

1. Setter. The default setter recognizes only two expressions of terms: either a literal, non-relative date in the fixed format 'yyyy-mm-dd' (known as ISO 8601), or a special string used for open-ended embargo (the default configured value for this is 'forever', but this can be changed in dspace.cfg to 'toujours', 'unendlich', etc). It will perform a minimal sanity check that the date is not in the past. Similarly, the default setter will only remove all read policies as noted above, rather than applying more nuanced rules (e.g allow access to certain IP groups, deny the rest). Fortunately, the setter class itself is configurable and you can 'plug in' any behavior you like, provided it is written in java and conforms to the setter interface. The dspace.cfg property:

   Code Block
   # implementation of embargo setter plugin - replace with local implementation if applicable plugin.single.org.dspace.embargo.EmbargoSetter = org.dspace.embargo.DefaultEmbargoSetter

   controls which setter to use.
2. Lifter.The default lifter behavior as described above‚Äîessentially above‚ essentially applying the collection policy rules to the item‚Äîmight item‚ might also not be sufficient for all purposes. It also can be replaced with another class:

   Code Block
   # implementation of embargo lifter plugin--replace with local implementation if applicable plugin.single.org.dspace.embargo.EmbargoLifter = org.dspace.embargo.DefaultEmbargoLifter

...

Step-by-Step Setup Examples

1. Simple Dates.If you want to enter simple calendar dates for when an embargo will expire, follow these steps.
   1. Select a metadata field. Let's use dc.description.embargo. This field does not exist in in the default DSpace metadata directory, so login as an administrator, go the metadata registry page, select the 'dc' schema, then add the metadata field.unmigrated-wiki-markup
   2. Expose the metadata field. Edit _\[dspace\]/config/input-forms.xml_ . If you have only one form‚Äîusually form‚ usually 'traditional', add it there. If you have multiple forms, add it only to the forms linked to collections for which embargo applies:

      Code Block
      <form name="traditional"> <page number="1"> …... <field> <dc-schema>dc</dc-schema> <dc-element>description</dc-element> <dc-qualifier>embargo</dc-qualifier> <repeatable>false</repeatable> <label>Embargo Date</label> <input-type>onebox</input-type> <hint>If required, enter date 'yyyy-mm-dd' when embargo expires or 'forever'.</hint> <required></required> </field>

      Note: if you want to require embargo terms for every item, put a phrase in the <required> element. Example:<required>You must enter an embargo date</required>
   3. Wiki MarkupConfigure Embargo. Edit _\[dspace\]/config/dspace.cfg_. Find the Embargo properties and set these two:

      Code Block
      # DC metadata field to hold the user-supplied embargo terms embargo.field.terms = dc.description.embargo # DC metadata field to hold computed "lift date" of embargo embargo.field.lift = dc.description.embargo

   4. Restart DSpace application. This will pick up these changes. Now just enter future dates (if applicable) in web submission and the items will be placed under embargo. You can enter years ('2020'), years and months ('2020-12'), or also days ('2020-12-15').unmigrated-wiki-markup
   5. Periodically run the lifter. Run the task:_\[dspace\]/bin/dspace embargo-lifter_You will want to run this task in a cron-scheduled or other repeating way. Item embargoes will be lifted as their dates pass.
2. Period Sets. If you wish to use a fixed set of time periods (e.g. 90 days, 6 months and 1 year) as embargo terms, follow these steps, which involve using a custom 'setter'.
   1. Select two metadata fields. Let's use 'dc.embargo.terms' and 'dc.embargo.lift'. These fields do not exist in the default DSpace metadata registry. Login as an administrator, go the metadata registry page, select the 'dc' schema, then add the metadata fields.unmigrated-wiki-markup
   2. Expose the 'term' metadata field. The lift field will be assigned by the embargo system, so it should not be exposed directly. Edit _\[dspace\]/config/input-forms.xml_ . If you have only one form (usually 'traditional') add it there. If you have multiple forms, add it only to the form(s) linked to collection(s) for which embargo applies. First, add the new field to the 'form definition':

      Code Block
      <form name="traditional"> <page number="1"> …... <field> <dc-schema>dc</dc-schema> <dc-element>embargo</dc-element> <dc-qualifier>terms</dc-qualifier> <repeatable>false</repeatable> <label>Embargo Terms</label> <input-type value-pairs-name="embargo_terms">dropdown</input-type> <hint>If required, select embargo terms.</hint> <required></required> </field>

      Note: If you want to require embargo terms for every item, put a phrase in the <required> element, e.g._<required>You must select embargo terms</required>_Observe that we have referenced a new value-pair list: "embargo_terms'. We must now define that as well (only once even if references by multiple forms):

      Code Block
      <form-value-pairs> …... <value-pairs value-pairs-name="embargo_terms" dc-term="embargo.terms"> <pair> <displayed-value>90 days</displayed-value> <stored-value>90 days</stored-value> </pair> <pair> <displayed-value>6 months</displayed-value> <stored-value>6 months</stored-value> </pair> <pair> <displayed-value>1 year</displayed-value> <stored-value>1 year</stored-value> </pair> </value-pairs>

      Note: if desired, you could localize the language of the displayed value.
   3. Configure Embargo. Edit /dspace/config/dspace.cfg. Find the Embargo properties and set the following properties:

      Code Block
      # DC metadata field to hold the user-supplied embargo terms embargo.field.terms = dc.embargo.terms # DC metadata field to hold computed "lift date" of embargo embargo.field.lift = dc.embargo.lift # implementation of embargo setter plugin - replace with local implementation if applicable plugin.single.org.dspace.embargo.EmbargoSetter = org.dspace.embargo.DayTableEmbargoSetter

Now add a new property called 'embargo.terms.days' as follows:

...

# DC metadata field to hold computed "lift date" of embargo
    embargo.terms.days = 90 days:90, 6 months:180, 1 year:365

1. 1. This step is the same as Step A.4 above, except that instead of entering a date, the submitter will select a value form a drop-down list.

1. 1. Wiki MarkupPeriodically run the lifter. Run the task:_\
      [dspace\]/bin/dspace embargo-lifter_ .
      You will want to run this task in a cron-scheduled or other repeating way. Item embargoes will be lifted as their dates pass.

Checksum Checker Settings

Wiki MarkupDSpace now comes with a Checksum Checker script (_\[dspace\]/bin/dspace checker_) which can be scheduled to verify the checksum of every item within DSpace. Since DSpace calculates and records the checksum of every file submitted to it, this script is able to determine whether or not a file has been changed (either manually or by some sort of corruption or virus). The idea being that the earlier you can identify a file has changed, the more likely you'd be able to recover it (assuming it was not a wanted change).

...

It is possible for an authorized user to request a complete export and download of a DSpace item in a compressed zip file. This zip file may contain the following:
dublin_core.xmllicense.txtcontents xml
license.txt
contents (listing of the contents)_
handle _file itself and the extract file if available

The configuration settings control several aspects of this feature:

...

DSpace, through some advanced installation and setup, is able to send out an email to collections that a user has subscribed. The user who is subscribed to a collection is emailed each time an item id added or modified. The following property key controls whether or not a user should be notified of a modification.

...

The following configurations allow the administrator extract from the DSpace database a set of records for editing by a metadata export. It provides an easier way of editing large collections.

bulkedit.fieldseparator = tab

bulkedit.ignore-on-export = dc.date.accessioned, \
                            dc.date.available, \
                            dc.date.updated, dc.description.provenance

...

It is now possible to hide metadata from public consumption that is only available to the Administrator.

...

These settings control two aspects of the submission process: thesis submission permission and whether or not a bitstream file is required when submitting to a collection.

...

This enables the Creative Commons license step in the submission process of the JSP User Interface (JSPUI). Submitters are given an opportunity to select a Creative Common license to accompany the item. Creative Commons license govern the use of the content. For further details, refer to the Creative Commons website at http://creativecommons.org .

...

General Web User Interface Configurations
In this section of Configuration, we address the agnostic WEB User Interface that is used for JSP UI and XML UI. Some of the configurations will give information towards customization or refer you to the appropriate documentation.