{"id":19640601,"url":"https://github.com/daniel-km/omeka-s-module-access","last_synced_at":"2026-01-23T13:58:13.164Z","repository":{"id":148008228,"uuid":"235175599","full_name":"Daniel-KM/Omeka-S-module-Access","owner":"Daniel-KM","description":"Module for Omeka S to protect access to selected files to visitors and guests, globally, by ip or individually, on request or token.","archived":false,"fork":false,"pushed_at":"2025-11-03T08:41:07.000Z","size":1336,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-11-03T10:20:28.746Z","etag":null,"topics":["access-control","omeka-s","omeka-s-module","protect"],"latest_commit_sha":null,"homepage":"","language":"PHP","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Daniel-KM.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2020-01-20T18:58:41.000Z","updated_at":"2025-11-03T08:41:11.000Z","dependencies_parsed_at":"2023-09-29T08:18:06.525Z","dependency_job_id":"e2576386-4970-4656-a80b-17fc4bcdd8ec","html_url":"https://github.com/Daniel-KM/Omeka-S-module-Access","commit_stats":null,"previous_names":[],"tags_count":37,"template":false,"template_full_name":null,"purl":"pkg:github/Daniel-KM/Omeka-S-module-Access","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Daniel-KM%2FOmeka-S-module-Access","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Daniel-KM%2FOmeka-S-module-Access/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Daniel-KM%2FOmeka-S-module-Access/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Daniel-KM%2FOmeka-S-module-Access/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Daniel-KM","download_url":"https://codeload.github.com/Daniel-KM/Omeka-S-module-Access/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Daniel-KM%2FOmeka-S-module-Access/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28693427,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-23T11:01:27.039Z","status":"ssl_error","status_checked_at":"2026-01-23T11:00:26.909Z","response_time":59,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["access-control","omeka-s","omeka-s-module","protect"],"created_at":"2024-11-11T14:06:14.010Z","updated_at":"2026-01-23T13:58:13.154Z","avatar_url":"https://github.com/Daniel-KM.png","language":"PHP","funding_links":[],"categories":[],"sub_categories":[],"readme":"Access (module for Omeka S)\n===========================\n\n\u003e __New versions of this module and support for Omeka S version 3.0 and above\n\u003e are available on [GitLab], which seems to respect users and privacy better\n\u003e than the previous repository.__\n\n[Access] is a module for [Omeka S] that allows to protect files to be accessed\nfrom the anonymous visitors, but nevertheless available globally or on requests\nby guests users, reserved to a list of ips, or available by an email or a token.\nStart and end dates of an embargo can be used too, separately or not.\n\nSee [below](#usage) for more information on usage.\n\nYou may use module [Guest Private] to access public or private resources on\nprivate sites.\n\n\nInstallation\n------------\n\n### Associated modules\n\nTo allow access to reserved resources for user with role \"Guest\", the module\nwill need to identify users, generally with the module [Guest] or [Guest Role].\n\nTo define specific item sets, you can use standard item sets or use the module\n[Dynamic Item Sets] to include items automatically in specific items sets\naccording to metadata.\n\nFor old themes, the public part can be managed easily via the module\n[Blocks Disposition], but it is recommended to use resource page blocks for new\nthemes.\n\nThe module is compatible with the module [Statistics]. It is important to\nredirect download urls to the module (see below config of \".htaccess\").\n\nThe module is compatible with the module [Derivative Media] that allows to use\nspecific derivative files instead original (for example a standard mp4 instead\nof a proprietary and unreadable Microsoft wmf). Note the paths should be added\nto the Apache config (htaccess).\n\n### Incompatibility\n\nUntil version 3.4.16, the module was not compatible with module [Group].\n\n### Installation of the module\n\nSee general end user documentation for [installing a module].\n\nThis module requires the module [Common], that should be installed first.\n\n* From the zip\n\nDownload the last release [Access.zip] from the list of releases, and uncompress\nit in the `modules` directory.\n\n* From the source and for development:\n\nIf the module was installed from the source, rename the name of the folder of\nthe module to `Access`.\n\n* For test\n\nThe module includes a comprehensive test suite with unit and functional tests.\nRun them from the root of Omeka:\n\n```sh\nvendor/bin/phpunit -c modules/Access/phpunit.xml\n```\n\n### Configuration of the web server\n\nOmeka does not manage the requests of the files of the web server (generally\nApache or Nginx): they are directly served by it, without any control. To\nprotect them, you have to tell the web server to redirect the users requests to\nOmeka, so it can check the rights, before returning the file or a forbidden\nresponse. You can adapt `routes.ini` as you wish too, but this is useless in\nmost of the cases.\n\n#### Apache\n\nThe Apache file \".htaccess\" at the root of Omeka should be updated to avoid\ndirect access to files and to redirect urls to the module.\n\nFor that, you have to adapt the following code to your needs in the main [.htaccess]\nat the root of Omeka, in a `.htaccess` file in the `files` directory, or\ndirectly in the config of the virtual host of the server (quicker). The example\nbelow is written for the Omeka [.htaccess] file. If you prefer to use other\nfiles, adapt the paths.\n\nIn this example, all original and large files will be protected: a check will be\ndone by the module before delivering files. If the user has no access to a file,\na fake file is displayed.\n\nThe small derivatives files (medium and square thumbnails), can be protected too,\nbut it is generally useless. Anyway, it depends on the original images.\n\nDon't forget to add derivative paths if you use module [Derivative Media].\n\nIf you choose the flag [L], Apache will use the module ModRewrite, that is\nalready installed for Omeka. For the flag [P], you should enable the module\nProxy and restart Apache:\n\n```sh\n# Depending on your config, either:\nsudo a2enmod proxy\n# Or something similar:\nsudo a2enmod proxy_fcgi\n# Then:\nsudo systemctl restart apache2\n```\n\n##### When Omeka S is installed at the root of a domain or a sub-domain\n\nInsert the following lines at line 4 of [.htaccess], just after `RewriteEngine On`,\neventually adding `|medium|square` to the list of thumbnails:\n\n```apache\n# Set rule for original and selected derivative files (usually at least large thumbnails).\nRewriteRule \"^/files/(original|large)/(.*)$\" \"/access/files/$1/$2\" [P]\n```\n\nAn alternative with flag [NC,L], without need of mod proxy:\n\n```apache\n# Set rule for original and selected derivative files (usually at least large thumbnails).\nRewriteRule \"^/files/(original|large)/(.*)$\" \"%{REQUEST_SCHEME}://%{HTTP_HOST}/access/files/$1/$2\" [NC,L]\n```\n\nThe request scheme (http or https) is needed when you set the domain, but you can\nwrite it directly without the constant `%{REQUEST_SCHEME}`.\n\n##### When Omeka S is installed in a sub-path (https://example.org/digital-library/)\n\nInsert the following lines at line 4 of [.htaccess], just after `RewriteEngine On`,\nadapting it to your real config (here, the sub-path is `digital-library`),\neventually adding `|medium|square` to the list of thumbnails:\n\n```apache\n# Set rule for original and selected derivative files (usually at least large thumbnails).\nRewriteRule \"^/files/(original|large)/(.*)$\" \"/digital-library/access/files/$1/$2\" [P]\n```\n\n##### Common issues\n\nFirst, try with the alternative (flag [P] or [L]).\n\n- Unable to redirect to a virtual proxy with https\n\n  The config uses flag `[P]` for an internal fake `Proxy`, so Apache rewrites\n  the path like a proxy. So if there is a redirection to a secured server\n  (https), the certificate should be running and up-to-date and the option\n  `SSLProxyEngine on` should be set in the Apache config of the web server.\n\n  Anyway, if you have access to it, you can include all rules inside it\n  directly (`ProxyPass`). If you don't have access to the Apache config, just\n  use the full unsecure url with `http://` (with real domain or `%{HTTP_HOST}`),\n  for the internal proxy. Because it is a fake proxy, it doesn't matter if the\n  internal redirect url is unsecure:\n\n```apache\n# Set rule for original and selected derivative files (usually at least large thumbnails).\nRewriteRule \"^/files/(original|large)/(.*)$\" \"http://%{HTTP_HOST}/digital-library/access/files/$1/$2\" [P]\n```\n\n- Remove the leading \"/\" before \"files/\", for example:\n\n```apache\nRewriteRule \"^files/(original|large|medium|square)/(.*)$\" \"%{REQUEST_SCHEME}://%{HTTP_HOST}/access/files/$1/$2\" [NC,L]\n```\n\n#### Compatibility with module Statistics\n\nThe module is compatible with the module [Statistics].\n\nBecause Omeka doesn't protect files by default, **it is important to redirect the urls of the original files**\nto the routes of the module Access. If you keep the redirection with `download`,\nthe check for reserved access won't be done, so **a private file will become public**,\neven if a user as a no reserved access to it. For example:\n\n```apache\n# Redirect direct access to files to the module Access.\nRewriteRule \"^/files/(original|large)/(.*)$\" \"/access/files/$1/$2\" [P]\n\n# Redirect direct download of files to the module Access.\nRewriteRule \"^/download/files/(original|large)/(.*)$\" \"/access/files/$1/$2\" [P]\n```\n\nIn fact, if not redirected, it acts the same way than a direct access to a\nprivate file in Omeka: they are not protected and everybody who knows the url,\nin particular Google, the well-known private life hacker, via Gmail, Chrome,\nAndroid, etc., will have access to it, even if it's exactly what you don't want.\n\n#### Nginx\n\nThe configuration of Apache above should be adapted for Nginx.\n\n\nUsage\n-----\n\nOmeka has two modes of visibility: public or private. This module adds a second\ncheck for anonymous or specific users: the right to access to a resource. This\nrights has four levels: free, reserved, protected or forbidden. These access\nlevels applies on record or media files, but the current version supports only\nprotection of media contents. The mode protected is not used in current version.\nFurthermore, a check is done on embargo dates, if any.\n\nSo with this module, there are three conditions to make a file accessible by a\nvisitor or a user:\n- visibility of the item and the media should be public;\n- access level should be free for anonymous visitor or reserved if the user has\n  some rights defined in config;\n- embargo dates should be undefined or ended.\n\nSo an anonymous visitor can see a public media, but can view the file only if\nthe level is set to free. The user should have a permission when the level is\nreserved or protected, and cannot see it in any case when the level is\nforbidden, even if the media is public.\n\nThere is no difference between reserved or protected when the type of protection\nis limited to files, that is the only type in the current version of the module.\n\nThe permission to see a reserved content can be done via many ways: Users can be\nchecked via the role guest, the authentication via an external identity provider\n(module [CAS], [LDAP] and [Single Sign-On]), by ip (v4 or v6), by email or by a\ntoken.\n\nOne important thing to understand is to choose to define the access for each\ntype of resource: item sets, items and media and to choose if the access is done\nrecursively during storing or in request. If the request is set to apply\nrecursively for an item set, all items and medias attached to it will be\navailable. If the request is set to apply recursively for an item, all medias\nattached to it will be available. So when an item set or an item is saved and\nwhen a request is validated, set if the access or the request applies\nrecursively.\n\nTake care that for resource, the recursivity should be set each time it is\nsaved, if needed, else access won't be updated to the attached resources. It\nallows to have specific access for specific items or medias. Furthermore, this\nmechanism does not apply when the access status is set via property. In that\ncase, all resources are managed individually.\n\nAnyway, the recursivity is useful only when there are multiple medias and the\nstatus of some of them is different.\n\nFinally, the option applies only to existing resources: if an item is created\nafter a change in an item set, it won't apply to it, so you will need to set the\nright mode or to update the item set with the recursive option set.\n\nWhen an embargo is set, it can be bypassed, or not, for the users. Only files\ncan be under embargo currently.\n\n### Access mode\n\nThe rights to see the files are controlled on the fly. The reserved visibility\ncan be managed in multiple ways:\n\n- Global modes\n  - `ip`: all visitors with a specific ip, for example the ip of the physical\n    library or the one of a researcher, can have access to all the reserved\n    files. Ip can be configured to access specific item sets, for example\n    `123.45.67.89 = 51, 54`\n  - `guest`: all guest users have access to all the reserved files.\n  - `auth_external`: all users authenticated via an external identity provider\n    (currently via module CAS and SingleSignOn, later for Ldap) have access\n    to media contents.\n  - `auth_cas`: all users authenticated via CAS (module CAS) have access to all\n    reserved files.\n  - `auth_ldap`: all users authenticated via Ldap (module Ldap) have access to\n    all reserved files (currently unsupported).\n  - `auth_sso`: all users authenticated via SAML/Shibboleth (module SingleSignOn)\n    have access to all reserved files.\n  - `auth_sso_idp`: users authenticated by specified identity providers have\n    access to a list of reserved media by item sets.\n  - `email_regex`: all authenticated users with an email matching a regex\n    pattern have access to all reserved files.\n- Individual modes\n  - `user`: each file should be made accessible by a specific user one by\n    one. So the module has some forms to manage individual requests and accesses.\n  - `email`: anybody authenticated via an email have access to specific media\n    contents. This protection is simple and light, but not the most secure.\n  - `token`: all users or visitor authenticated via a token have access to\n    specific media contents.\n\nIndividual modes require that an admin allow each right for each resource.\n\n### Identification of the reserved resources\n\nAfter the configuration, you should identify all resources that you want to make\navailable via a reserved access. By default, private resources remain private,\nso you need to allow visitors to know that they exist. That is to say you can\nkeep some private resources private, and some other ones available on request,\nor globally.\n\nThere are two ways to indicate which resources are reserved.\n\n- By default, it is a specific setting available as a radio button in the\n  advanced tab of the resource form.\n- The second way is to set a value to a specified property, for example\n  `dcterms:accessRights` or `curation:access`.\n  The default values are \"free\", \"reserved\", \"protected\" or \"forbidden\". The\n  property and the names can be translated or modified in the config. It is\n  recommended to create a custom vocab and to use it via the resource templates\n  to avoid errors in the values.\n\nA private media remains private. A public media will be accessible only if its\nstatus is not forbidden and not during an embargo, if any.\n\nNote that a public item can have a private media and vice-versa. So, most of the\ntime, the value should be set in the metadata of the media. The value can be\nspecified for the item too to simplify management.\n\n### Inheritance behavior\n\nWhen a media does not have an explicit access status set:\n\n- **At runtime**: The media inherits the access level and embargo settings from\n  its parent item. If neither the media nor the item has an access status, the\n  media content is accessible (free by default).\n- **On save with property mode**: When access is managed via properties, if a\n  media does not have the access level property set, it will inherit the value\n  from the parent item property. The same applies to embargo start and end\n  properties.\n- **On save without property mode**: When creating new medias via an item, the\n  item access data is applied to the new medias by default. Use the \"recursive\"\n  option to explicitly copy access settings to all medias.\n\nThis inheritance behavior ensures that restricted items have their medias\nrestricted as well, even when access is not explicitly set on individual medias.\n\n### Advanced search\n\nThe advanced search form includes a multi-select filter for access levels. You\ncan select multiple levels to search for resources matching any of the selected\nlevels. When no levels are selected, all resources are returned regardless of\ntheir access level.\n\n### Item sets\n\nAs indicated above, it is possible to define specific rights by item sets when\nusing some access mode, mainly ip and sso idp.\n\nTo define a specific rights, set the ip or the idp, then \"=\", then the item set\nids to which the ip or the idp can access. If there is no item set defined, the\ncheck will be defined per item. Each item set may be prepended with a \"-\" to\nforbid access to a specific item set. This option is useful when a global item\nset is defined to identify all reserved resources. When a federation like\nRenater is used, set \"federation =\" then the item sets.\n\nThe order matters: the user is checked in the order of the list, so the\nfederation is generally specified at last.\n\nThe use of the module [Dynamic Item Sets] may be useful, because it allows to\ndefine items included in a item sets according to a standard query.\n\n#### Example for the access mode \"ip\"\n\n```\n12.34.56.78\n124.8.16.32 = 17 89 -1940\n65.43.21.0/24 = -2005\n```\n\nHere, the user identified via the first ip has access to all reserved resources;\nthe user identified via the second ip has access to item sets #17 and #89, but\nnot to item set #1940. The federation has access to all items, except those of\nitem set 2005.\n\n#### Example for the access mode \"sso idp\"\n\n```\nidp.example.org =\nshibboleth.another-example.org = 17 89 -1940\nfederation = -2005\n```\n\nHere, the user identified via idp.example.org has access to all reserved\nresources; the user identifier via the second idp has access to item sets #17\nand #89, but not to item set #1940. The federation has access to all items,\nexcept those of item set #2005.\n\n### Embargo\n\nBy construction, the embargo works only on the media files: metadata are always\nvisible for public and reserved resources.\n\nAn option in the config can be used to use it with or without the reserved\naccess.\n\nTo create an embargo on a file, simply set the dates in the advanced tab or use\nproperties `curation:start` and/or `curation:end`, or the ones specified in the\nconfig.\n\nIf you use a property to define the date of the embargo, it is recommended to\nuse the datatype \"numeric timestamp\" from the module [Numeric Datatypes], but a\nliteral is fine. The date must be an iso one (`2022-03-14`). A time can be set\ntoo (`2022-03-14T12:34:56`).\n\n**Important**: Generally, it is enough to set the embargo on the item. Set it on\nmedias only when there are multiple medias with various status or date of\nembargo.\n\nTwo settings control what happens when an embargo ends:\n\n- What to do with the access level:\n  - `free`: Set access level to \"free\"\n  - `under`: Set access level to the level under (\"free\" for reserved, \"reserved\"\n    for protected/forbidden)\n  - `keep`: Keep the current access level\n- What to do with the embargo dates:\n  - `clear`: Remove the embargo dates\n  - `keep`: Keep the embargo dates\n\nA job is run automatically once a day to update access status and embargo.\n\nFurthermore, a check is automatically done when an anonymous visitor or a\nrestricted user is accessing a restricted file. In that case, the media may be\nset public automatically when the embargo is finished.\n\nThe job does not update the resource when the visibility is not logical, for\nexample when the resource have been set public with a date of end of embargo.\nOf course, don't set a date of end of embargo if the record is not ready or when\nit should remain private.\n\n### Management of requests\n\nIf you choose modes `ip`, `guest`, or `external`, there is nothing to do more.\nOnce users are authenticated or authorized, they will be able to see the files.\n\nIn the case of the single modes `user`, `email` or `token`, there are two ways\nto process.\n\n- The admin can made some item sets, items or medias available directly in the\n  menu \"Access requests\" in the sidebar. Simply add a new access, select a\n  resource and a user, a email or a token, and the person will be able to view\n  it.\n\n- The user or visitor can request an access to a specific resource. It can be\n  done directly via a button, for logged users, or via a contact form for the\n  anonymous visitors. The contact form may be added by this module or the module\n  [Contact Us]. After the request, the admin will receive an email to accept or\n  reject the request.\n\nOnce accepted, the requester will receive an email with an url to click, that\nwill add a session cookie that will allow to browse the selected resources.\n\nIn public front-end, a dashboard is added for visitors: `/s/my-site/access-request`.\nGuest users have a specific board too: `/s/my-site/guest/access-request`.\n\n### Check of status levels\n\nIn some cases, when the status is stored in a property, you may want to check if\nall resources values statuses are well stored in the table access_status. Here\nare some sql queries for that, with French values and where curation:access is\nused (property 185 here):\n\n```sql\n# Items\nSELECT `access_status`.`id`, `access_status`.`level`, `resource`.`is_public`\nFROM `value`\nINNER JOIN `access_status` ON `value`.`resource_id` = `access_status`.`id`\nINNER JOIN `item` ON `item`.`id` = `access_status`.`id`\nINNER JOIN `resource` ON `resource`.`id` = `item`.`id`\nWHERE `value`.`property_id` = 185\n    AND `value`.`value` = \"Accès libre\"\n    AND `access_status`.`level` != 'free';\n\nSELECT `access_status`.`id`, `access_status`.`level`, `resource`.`is_public`\nFROM `value`\nINNER JOIN `access_status` ON `value`.`resource_id` = `access_status`.`id`\nINNER JOIN `item` ON `item`.`id` = `access_status`.`id`\nINNER JOIN `resource` ON `resource`.`id` = `item`.`id`\nWHERE `value`.`property_id` = 185\n    AND `value`.`value` = \"Accès restreint\"\n    AND `access_status`.`level` != 'reserved';\n\nSELECT `access_status`.`id`, `access_status`.`level`, `resource`.`is_public`\nFROM `value`\nINNER JOIN `access_status` ON `value`.`resource_id` = `access_status`.`id`\nINNER JOIN `item` ON `item`.`id` = `access_status`.`id`\nINNER JOIN `resource` ON `resource`.`id` = `item`.`id`\nWHERE `value`.`property_id` = 185\n    AND `value`.`value` = \"Non consultable\"\n    AND `access_status`.`level` != 'forbidden';\n\n# Media\nSELECT `access_status`.`id`, `access_status`.`level`, `resource`.`is_public`\nFROM `value`\nINNER JOIN `access_status` ON `value`.`resource_id` = `access_status`.`id`\nINNER JOIN `media` ON `media`.`id` = `access_status`.`id`\nINNER JOIN `resource` ON `resource`.`id` = `media`.`id`\nWHERE `value`.`property_id` = 185\n    AND `value`.`value` = \"Accès libre\"\n    AND `access_status`.`level` != 'free';\n\nSELECT `access_status`.`id`, `access_status`.`level`, `resource`.`is_public`\nFROM `value`\nINNER JOIN `access_status` ON `value`.`resource_id` = `access_status`.`id`\nINNER JOIN `media` ON `media`.`id` = `access_status`.`id`\nINNER JOIN `resource` ON `resource`.`id` = `media`.`id`\nWHERE `value`.`property_id` = 185\n    AND `value`.`value` = \"Accès restreint\"\n    AND `access_status`.`level` != 'reserved';\n\nSELECT `access_status`.`id`, `access_status`.`level`, `resource`.`is_public`\nFROM `value`\nINNER JOIN `access_status` ON `value`.`resource_id` = `access_status`.`id`\nINNER JOIN `media` ON `media`.`id` = `access_status`.`id`\nINNER JOIN `resource` ON `resource`.`id` = `media`.`id`\nWHERE `value`.`property_id` = 185\n    AND `value`.`value` = \"Non consultable\"\n    AND `access_status`.`level` != 'forbidden';\n```\n\n\nTODO\n----\n\n- [x] Fix ip check for ipv6.\n- [ ] Use Omeka Store instead of local file system.\n- [ ] Update temporal to avoid to check embargo each time via php.\n- [x] Reindexation (trigger event?) when embargo is updated automatically. Use the cron task of module EasyAdmin?\n- [ ] Clarify process for embargo start and update embargo start date with a specific option (no one seems to use it anyway).\n- [ ] Add a mode cas_itemsets to define access rules by cas attributes and item sets (like sso_idp).\n\n\nWarning\n-------\n\nUse it at your own risk.\n\nIt’s always recommended to backup your files and your databases and to check\nyour archives regularly so you can roll back if needed.\n\n\nTroubleshooting\n---------------\n\nSee online issues on the [module issues] page on GitLab.\n\n\nLicense\n-------\n\n### Module\n\nThis module is published under the [CeCILL v2.1] license, compatible with\n[GNU/GPL] and approved by [FSF] and [OSI].\n\nThis software is governed by the CeCILL license under French law and abiding by\nthe rules of distribution of free software. You can use, modify and/ or\nredistribute the software under the terms of the CeCILL license as circulated by\nCEA, CNRS and INRIA at the following URL \"http://www.cecill.info\".\n\nAs a counterpart to the access to the source code and rights to copy, modify and\nredistribute granted by the license, users are provided only with a limited\nwarranty and the software’s author, the holder of the economic rights, and the\nsuccessive licensors have only limited liability.\n\nIn this respect, the user’s attention is drawn to the risks associated with\nloading, using, modifying and/or developing or reproducing the software by the\nuser in light of its specific status of free software, that may mean that it is\ncomplicated to manipulate, and that also therefore means that it is reserved for\ndevelopers and experienced professionals having in-depth computer knowledge.\nUsers are therefore encouraged to load and test the software’s suitability as\nregards their requirements in conditions enabling the security of their systems\nand/or data to be ensured and, more generally, to use and operate it in the same\nconditions as regards security.\n\nThe fact that you are presently reading this means that you have had knowledge\nof the CeCILL license and that you accept its terms.\n\n### Image Locked file\n\nThe image [Locked file] is licensed under [GNU/GPL].\n\n\nCopyright\n---------\n\n* Copyright Daniel Berthereau, 2019-2026 (see [Daniel-KM] on GitLab)\n* Copyright Saki (image [Locked file], see [Saki])\n\n\n[Access]: https://gitlab.com/Daniel-KM/Omeka-S-module-Access\n[Omeka S]: https://omeka.org/s\n[Guest Private]: https://gitlab.com/Daniel-KM/Omeka-S-module-GuestPrivate\n[Guest]: https://gitlab.com/Daniel-KM/Omeka-S-module-Guest\n[Guest Role]: https://github.com/biblibre/omeka-s-module-GuestRole\n[Dynamic Item Sets]: https://gitlab.com/Daniel-KM/Omeka-S-module-DynamicItemSets\n[Blocks Disposition]: https://gitlab.com/Daniel-KM/Omeka-S-module-BlocksDisposition\n[Derivative Media]: https://gitlab.com/Daniel-KM/Omeka-S-module-DerivativeMedia\n[Group]: https://gitlab.com/Daniel-KM/Omeka-S-module-Group/-/releases\n[Contact Us]: https://gitlab.com/Daniel-KM/Omeka-S-module-ContactUs\n[CAS]: https://github.com/biblibre/Omeka-S-module-CAS\n[LDAP]: https://gitlab.com/Daniel-KM/Omeka-S-module-Ldap\n[Single Sign-On]: https://gitlab.com/Daniel-KM/Omeka-S-module-SingleSignOn\n[Numeric Datatypes]: https://github.com/omeka-s-modules/NumericDatatypes\n[Easy Admin]: https://gitlab.com/Daniel-KM/Omeka-S-module-EasyAdmin\n[Statistics]: https://gitlab.com/Daniel-KM/Omeka-S-module-Statistics\n[installing a module]: https://omeka.org/s/docs/user-manual/modules/#installing-modules\n[Common]: https://gitlab.com/Daniel-KM/Omeka-S-module-Common\n[Access.zip]: https://gitlab.com/Daniel-KM/Omeka-S-module-Access/-/releases\n[Protect original files]: #protect-original-files\n[.htaccess]: https://github.com/omeka/omeka-s/blob/develop/.htaccess.dist#L4\n[module issues]: https://gitlab.com/Daniel-KM/Omeka-S-module-Access/-/issues\n[CeCILL v2.1]: https://www.cecill.info/licences/Licence_CeCILL_V2.1-en.html\n[GNU/GPL]: https://www.gnu.org/licenses/gpl-3.0.html\n[FSF]: https://www.fsf.org\n[OSI]: http://opensource.org\n[Locked file]: http://www.iconarchive.com/show/nuoveXT-icons-by-saki/Mimetypes-file-locked-icon.html\n[Saki]: http://www.iconarchive.com/artist/saki.html\n[GitLab]: https://gitlab.com/Daniel-KM\n[Daniel-KM]: https://gitlab.com/Daniel-KM \"Daniel Berthereau\"\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdaniel-km%2Fomeka-s-module-access","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdaniel-km%2Fomeka-s-module-access","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdaniel-km%2Fomeka-s-module-access/lists"}