Difference between revisions of "EPrints4 Core Roadmap"
(→Request Handler / Page Controllers) |
(→EPrints4 Core Development) |
||
| Line 21: | Line 21: | ||
* Low-level redirects or custom actions via Trigger | * Low-level redirects or custom actions via Trigger | ||
| − | * Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) | + | * Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) via Trigger |
| + | |||
| + | * clean-up/post-processing if needed (e.g. setting Cache headers etc). | ||
| + | |||
| + | ==Security== | ||
| + | |||
| + | Security (authentication and authorisation) must be handled by the Page Controller. They decide if auth is required at all (for instance a GET on an object via CRUD is usually allowed without auth). If auth may be required, the PerlAccessHandler stack must be defined. | ||
| + | |||
| + | It is worth noting that authentication is likely to be common to most Page Controllers. The typical authentication mechanisms are: Basic Auth (via HTTP Header) and Cookie/Session-based Auth. Session-based is mostly handled internally (via LoginTicket) but the way the credentials are retrieved can be customised (CAS, LDAP...). | ||
| + | |||
| + | Authorisation, on the other hand will be defined by the Page Controller. If the request is trying to modify an object, the Controller needs to check that the logged-in user has the appropriate rights/roles. | ||
Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time. | Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time. | ||
Revision as of 14:54, 6 February 2014
EPrints4 Core Development
Trying to divide the work into smaller tasks (and questions where relevant).
Request Handler / Page Controllers
This deals with how HTTP requests are handled by EPrints: when a request is made by a client (curl, browser..) a number of headers/parameters must be processed (e.g. Accept, Content-Type, EPrints' cookies, auth etc). This is the entry point of any web requests to the system. The main module is EPrints::Apache::Handler (formerly known as Apache::Rewrite).
- Basic security aspects
- detect invalid requests/URL paths (e.g. containing a dot '.')
- Low-level filters for processing of:
- Cookies (eprints_session, eprints_lang)
- URL encoding
- specific HTTP headers: Accept, Content-Type, Content-Length, Content-Range, Content-MD5 (?), ETag (?)
- System initialisation:
- Repository object init (with language selection, via cookie/default lang)
- Protocol (HTTP, HTTPS?)
- Low-level redirects or custom actions via Trigger
- Call for Controller(s) to handle the request (e.g. CRUD if /id/..., UI, storage (file delivery) etc.) via Trigger
- clean-up/post-processing if needed (e.g. setting Cache headers etc).
Security
Security (authentication and authorisation) must be handled by the Page Controller. They decide if auth is required at all (for instance a GET on an object via CRUD is usually allowed without auth). If auth may be required, the PerlAccessHandler stack must be defined.
It is worth noting that authentication is likely to be common to most Page Controllers. The typical authentication mechanisms are: Basic Auth (via HTTP Header) and Cookie/Session-based Auth. Session-based is mostly handled internally (via LoginTicket) but the way the credentials are retrieved can be customised (CAS, LDAP...).
Authorisation, on the other hand will be defined by the Page Controller. If the request is trying to modify an object, the Controller needs to check that the logged-in user has the appropriate rights/roles.
Filters must be called using Trigger(s) or similar mechanism to avoid having hard-coded modules in the Request handler. It is then easy to select, add, remove filters at run-time.
