----- Original Message ----- > From: "Casey Bodley" <cbodley@xxxxxxxxxx> > To: "The Sacred Order of the Squid Cybernetic" <ceph-devel@xxxxxxxxxxxxxxx> > Sent: Thursday, September 8, 2016 2:35:34 AM > Subject: Re: rgw: feedback on auth engine selection > > > 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 One more requirement to add to the list: - In case of AWS, two different methods (RGWPostObj_ObjStore_S3::get_policy() and RGW_Auth_S3::authorize), will be making use of the Auth Engines to authenticate a request and the auth key extraction method will be different for both of them. The auth infrastructure needs to take care of this. -- 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