Sure thing that’s fine.

FYI the Mailman REST authentication proxy works in this way:

** Python 3 only
** built using Falcon
** the proxy reads the structure of the Mailman 3 REST API by parsing the 
Mailman 3 Swagger API specification
** each Mailman 3 REST API URL/HTTP method call combination is defined in the 
Swagger spec and has a unique OperationID
** the proxy intercepts all inbound requests to the Mailman 3 REST API, this is 
done through Falcon’s “sink” capability
** the proxy does a regex match on the inbound URL and looks up the operationID 
to work out which Mailman 3 REST API method is being called
** in the proxy a set of request handlers is defined for each Mailman 3 API 
operation 
** the inbound request is pushed through the request handlers, typically the 
final request handler proxies the authenticated request to the Mailman REST 
API, unless one of the request handlers aborts the processing due to some sort 
of auth issue

A typical example of one API operation mapping to its set of handlers looks 
something like this:

{‘UsersGet’: [validateJSONAuthToken, refreshJSONAuthToken, userMustbeListAdmin, 
proxyRequestToMailman]}

In the above example the inbound request goes through a handler that validates 
its JWT authentication token, a handler that refreshes its JWT token, a handler 
that checks to ensure that the requesting user (as identified from the JWT 
token) has the appropriate rights to carry out the requested Mailman 3 
operation, then the request is proxied to the Mailman REST API and the result 
is send back to the client/requestor.

JSON web token authentication is automatically layered on top of the API.

Typically you would want the authenticating proxy to sit behind a reverse proxy 
such as HAproxy or Nginx which would do gzip compression and SSL.

Most of this is working.

as


On 22 Jan 2015, at 2:57 am, Barry Warsaw <ba...@list.org> wrote:

On Jan 22, 2015, at 12:02 AM, Andrew Stuart wrote:

> Barry - would you like the authenticating proxy to be part of Mailman core or
> a third party project?

For now, I think it should not be distributed as part of core.  Maybe after
the 3.0 release.  The code could still be donated to the FSF and managed under
the GNU Mailman project in a separate source repository.  That's kind of your
call; let me know if you'd like to do that.

> It’s close to being functionally operational (which is to say working but in
> a raw state).

Very cool.  Thanks for working on this important piece.

Cheers,
-Barry
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40supercoders.com.au

Security Policy: http://wiki.list.org/x/QIA9

_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Reply via email to