John Salter and John Beaman, University of Leeds

==Intro==
* Hello: we're John Salter and John Beaman from the University of Leeds.
* We've spent some time trying to write an Access Control system for EPrints. ''It's been a horror.''
* One of our use-cases is for Research Data, but it could be used on other repository types.

==Out of the box User Access Control==
* EPrints ''(you all know what this is, right..?)'' has basic control at the document level - the 'security' field:
** public (Open Access)
** validuser (anyone who's got an account on that EPrints instance)
** staffonly (Repository editors/admins)
* This doesn't cover the requirements for some repositories...

==Requirements==
* Control access to EPrints, Documents
* Control access based on:
** User attributes e.g. signed-in via Shibboleth
** Location e.g. on-campus
* Simple interface to assign restrictions

==EPACL: EPrints Access Control Layer==
* Doesn't overwrite any existing 'security' specified on documents.

===ACL_Roles===
* Fields
** ID
** ACL_Authority e.g. LDAP; IP address; EPrintsUser
** Role title
** Role description
** Filter e.g. member of a specific LDAP group; EPrintsUser type = editor;

===ACL_Groups===
* Fields
** ID
** Group name
** Group description
** ACL_Roles
** Role combination (AND / OR)

===ACL_Authority===
???

==Dealing with rejection==
* What happens when someone is denied access?
** Document landing pages
** Restricted summary pages
** Contact details to request access?

==ACL Objects==
*ACL Authority
**Corresponds to a method of authorisation (e.g. Shibboleth, LDAP etc.)

*ACL Role
**Authorised by an ACL Authority with zero or more 'filters' applied
**Filters act as additional requirements (e.g. ACL_Authority='LDAP', Filter='dc=leeds.ac.uk')

*ACL Group
**Each ACL Group consists of one or more ACL Roles
**The ACL Roles are combined within an ACL Group by being 'OR'ed or 'AND'ed together
**One or more ACL Groups are applied to EPrints data objects (e.g. eprints, documents)
**The ACL Groups applied to EPrints data objects are 'OR'ed or 'AND'ed togther

==Summary Page citation style==
*How do we deal with rejected requests (i.e. what do we show)?
*We can define different citation styles depending on whether the request is allowed or denied
*'Restricted' citations may be required (e.g. to satisfy the minimum metadata requirements of a DOI)

==Document-level landing pages==
*Born out of DOI requirements
*Individual documents may have their own DOI, so ideally need their own 'landing page'
*Document landing pages should contain at least the mandatory metadata fields if linked from a DOI

==Request vs User==
*Two basic steps to authorise access - request and user
*First EPrints checks if the request has appropriate access rights
*If so, any additional user requirements are also checked
*If not, the request is denied (since the user's credentials are irrelevant at that point)

==Homeless thoughts==
*Summary Page citation style
*Access logging
*Login sources
*Modular design
*Request vs User
*Describe ACL_Group, ACL_Role, ACL_Authority
*DOIs at Doc level = landing page citation style

API:bin/import

2014-04-28T11:37:31Z

J.beaman@leeds.ac.uk:

{{API}}{{Pod2Wiki}}{{API:Source|file=bin/import|package_name=bin/import}}[[Category:API|BIN/IMPORT]][[Category:API:bin/import|BIN/IMPORT]][[Category:API:bin/import|BIN/IMPORT]]<div>


==NAME==
'''import''' - Import a file using an import plugin.





==SYNOPSIS==
'''import''' repository_id ['''options'''] dataset

'''import''' repository_id ['''options'''] dataset plugin filename





==DESCRIPTION==
This command imports a set of EPrints from a file into the given dataset.





==ARGUMENTS==
* repository_id
: The ID of the EPrint repository to import to.

* dataset
: The name of the dataset to import into, such as "eprint","archive", "subject" or "user".

: Please note that for the "subject" dataset, you are probably better off using the import_subjects tool which will empty the dataset before importing.

* plugin
: The id of the input plugin to use. This should not include the leading "Import::". Examples: BibTeX, XML.

: If this is ommited or an invalid plugin is requested, then 'import' will list all plugins compatible with the dataset and exit.

* filename
: Filename to read from. To read from STDIN specify '-'.





==OPTIONS==
* '''--user USERID/USERNAME'''
: For eprint datasets only. (not user or subject).

: Sets the userid/username of the user in the system who will own the imported records.

: Usually required for importing EPrint records. This may not be required if the import format contains the userid value, eg. an import in the EPrints 3 XML format.

: If this is an integer then it is assumed to be the userid of the user, otherwise it is assumed to be the username.

: You may wish to create one or more "bulk import" users and make imported eprint records belong to them.

* '''--argument key=value'''
: Add an argument to the import plugin. May be repeated. Effects depend on the import plugin.

* '''--parse-only'''
: Don't import, just check the file.

* '''--migration'''
: Turn on all the options needed to correctly import an XML data file exported from version 2, using the migration toolkit. Implies --enable-web-imports --enable-file-imports --force

* '''--enable-import-fields'''
: Allow the import to set fields that are set as not to be imported. This is typically used to specify the imported object id.

* '''--enable-file-imports'''
: Allow the imported data to import files from the local filesystem. This can obviously be seen as a security hole if you don't trust the data you are importing. This sets the "enable_file_imports" configuration option for this session only.

* '''--enable-web-imports'''
: Allow the imported data to import files from the Web. This can obviously be seen as a security hole if you don't trust the data you are importing. This sets the "enable_web_imports" configuration option for this session only.

* '''--xml'''
: Output to STDOUT the parsed objects in EPrints XML (does not import anything).

* '''--update'''
: Normally you can not import a new item with the same id as an existing item. With this option enabled existing items will be updated with the new item. Combine with --enable-import-fields to update all field values.

* '''--force'''
: Don't ask any questions, just do it!

* '''--help'''
: Print a brief help message and exit.

* '''--man'''
: Print the full manual page and then exit.

* '''--quiet'''
: Be vewwy vewwy quiet. This option will supress all output unless an error occurs.

* '''--verbose'''
: Explain in detail what is going on. May be repeated for greater effect.

: Shows why a plugin is disabled.

* '''--version'''
: Output version information and exit.

<pre>

</pre>


'''Please note''' that the ''--update'' option described above '''will not''' work in EPrint versions prior to v3.3.12 without an edit to the bin/import module. See here for details. [https://github.com/eprints/eprints/commit/a5eb05abd14606d26f746e1f2d499bd11104c3ae]



==COPYRIGHT==
Copyright 2000-2011 University of Southampton.

This file is part of EPrints http://www.eprints.org/.

EPrints is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

EPrints is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with EPrints. If not, see http://www.gnu.org/licenses/.