[Mailman-Developers] How can I run the REST tests against live servers?

[Andrew Stuart]

I have managed to make the existing tests work through my proxy but it was challenging for a few reasons.

The tests are hard coded to transmit their HTTP requests on port 9001.

The assertEqual in the tests sometimes expect to see JSON data that includes, in some cases, absolute URLs with hard coded port numbers for example:  
"self_link": "http://localhost:9001/3.0/lists/bee.example.com"

To make the tests work I put my proxy at port 7001, changed the hard coded test requests to be transmitted to port 7001 instead of port 9001. 
I set  testing.cfg to 
[webservice]
port: 9001

Inside my proxy I configured all inbound queries to go to port 9001.

So the server returns data including port 9001 in the self link URLs, and the tests successfully find the expected port number.

Should “self links” to anything be hard coded to a host and port number? I did wonder whether the API should be returning self links as just relative URL (i.e. no http://hostname:port ) and it is up to something else to work out the host that the self link lives on.  

If self links include http://hostname:port then any proxy would need to transform the data on the way back top the client to remove or correct the host and port number.

Andrew





On 12 Dec 2014, at 11:34 am, Barry Warsaw <barry at list.org> wrote:

On Dec 12, 2014, at 08:35 AM, Andrew Stuart wrote:

> I’m writing an authenticating proxy for the Mailman REST API and want to make
> sure everything works as expected against real infrastructure
> (Postgres/Postfix/Sqlalchemy/Falcon).

We definitely want such a proxy.  It's always been our intent that the core's
REST API is an adminipstrative API with full access.  It should only be
exposed on localhost or other highly secure interface.

A proxy server such as you describe would be available on a public interface
and would allow people to script the management of their list memberships and
list administrations.

> I was hoping that just pointing the REST tests request port to my proxy would
> work but no dice - lots of failures - trying to diagnose the failures has led
> me back to trying to get the test suite to work against the live servers.
> 
> I’m wondering if maybe the shortest route here might not be for me to write a
> new set of tests which purely talk REST and don’t touch the back end directly
> at all.  Except that’s not a short route. :-)
> 
> Trying to bend the existing tests to meet my needs is looking harder than I
> have time to deal with.

Even in this case, I wouldn't expect the standard unittests to work.  For
example, if a normal user were to try to access the list admin API, you'd
expect that to fail.

I think one approach would be to continue to use the test servers, but have a
backdoor connection which would let you set up the state before each test and
reset the state after each test.  Then the tests themselves would use the
authenticated API to flex the things it can and shouldn't be able to do.
It would be possible for example to expose some helper resources in the admin
API which would not normally be exposed in production.  Something under a top
level /tests resource perhaps.

Cheers,
-Barry
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers at 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