On 09/07/2016 01:19 PM, Radoslaw Zarzynski wrote:
Anyway, before we start discussing the whole
auth stuff further, I guess it would be helpful to
write in one place all requirements/plans that
might affect this area. For instance, the idea of
RGWHandler rework can have such impact.
Let me start the requirements with an item found
after a session with Swift's FormPost middleware:
* the auth infrastructure must allow for easy-adoption
of new AuthEngines as even FormPost would need
one :-).
Some specific requirements that I recall from our past discussions include:
- don't heap allocate auth state per request
- don't construct or call into AuthEngines that shouldn't be enabled for
the given handler
I'll add some of the other refactoring goals we've discussed, but I
don't think they place any strict requirements on the auth subsystem:
- RGWHandler: being able to reuse handler instances, instead of
allocating a new one for each request
- req_state: contains too many unrelated fields, some of which are
transformed in confusing ways over the lifetime of the request. needs to
be broken up into smaller, better encapsulated sub-objects
- concurrency: move away from a synchronous process_request() to build
on asio frontend work
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
