XML-RPC authentication options for the validation dashboard

Zygmunt Krynicki zygmunt.krynicki at linaro.org
Tue Sep 7 16:52:12 BST 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/09/10 17:23, Paul Larson wrote:

>> Other options are (off the top of my head):
>> - - Basic/Digest HTTP authentication. Digest is pretty good (or so
>>
> I think this would fit our needs just fine.

I agree, and for the moment I'd like to pursue this route. It's the
fastest to develop/deploy and solves an important problem - having
access to secure APIs in a not-unreasonable manner (security-wise)

> - - No authentication at all. All XML-RPC interfaces are public and anyone
>> may call them. Surprisingly this is not such a bad option. Since all
>> request would be anonymous all the users would be allowed to do is
>> upload data to public "directories". All other interaction would have to
>> be performed via the website or the administration panel.
>>
> I can certainly see the logic here, and discounting the possibility of a
> nefarious spammer flooding our server with junk, I think it's worth
> consideration.  My concerns revolve around what it might complicate on the
> back end.  If we want to go this route, I think the impact needs to be
> better defined.

It's actually already done, there is no impact on the server. Simply,
all methods behave as if the user is not known. To add support for user
identification (authentication) you would have to tweak with the
xml_rpc_handler view and pass this down to each method as some kind of
argument. The latter is surprisingly more complicated. I still did not
figure out a pretty way of passing this non-parameter to the function.
There are ways of doing it but they don't seem clean.

>  - With lots of possible submissions, without any kind of identification
> attached to them, how do I find my submission in the haystack?

Well each submission gets an ID (so you know it when you submit) but
it's a difficult thing to solve in a *big* stream of bundles.

>  - You mentioned uploading to "directories", which could fix the above
> partially, but what prevents someone from uploading to my directory, even by
> accident (for instance, if they have a similar name and just happen to
> choose the same "path" as me)

I have a simple mechanism for this. You can create bundle streams which
are named containers for bundles. A bundle must be in exactly one
container. There are three kinds of containers:
 - public, they have a pathname like: /anonymous/ or /anonymous/NAME/
(where NAME is any single word that does not contain '/'). They are open
for reading/writing by anyone (note that there is no API for removing
bundles yet so there is no problem about who can remove something from
this stream)
 - private, they have a pathname like /personal/USERNAME/ or
/personal/USERNAME/NAME/ (NAME behaves as above). Only the owner may
access the contents.
- - team, like private but they belong to a group, the pathname is
/team/TEAMNAME/

>  - Are results publicly automatically?

Read access is determined by the bundle stream and accessing user identity.

  If not, who has the authority to
> approve them?

You'd have to define "approve". I suspect you are interested in being
able to mark some as "valid" and being included in reports. I suspect
that you could do such a thing by having two streams like
/something/incoming/ and /something/checked/ and moving bundles between
them as you see fit. If more control is needed please tell me what use
case you'd like to accommodate.

  And if you restrict access to this, aren't we back to
> providing an authentication mechanism again, but just complicating the
> process by which results are posted?

I'm not sure what's the answer to this. I think that posting results is
easy and what is offered now is sufficient. If you find a use case that
cannot be solved with current technology we can design a solution for that.

> ...
> You can see my line of thinking here I hope.  I'm not saying it's a bad
> option, just that there are some implementation details that span farther
> than just the auth stage that need to be clearly defined first, if we want
> to go in this direction.

Mmm. Right, the whole how do we use this in practice thing. I think that
it's going to be usable and initially we will use digest authentication
and team streams where a group of trusted members can shuffle the data
so that it makes sense.

Thanks
Zygmunt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMhl+rAAoJEKkR4hQBRI+lLoAH/0oXESzoCq+URPkO+kD637Zl
v+UtO6XGGrnXbShRFQnW2NhAgyPpp2qXjBU4Fs3vl+W0Nj9mhhtV/2seb0ZzLr59
6I0NSy9KEdMjiclT8zLhJXDNoMAQW+RaxS5W8pRpl24HDz7IAmmYu0PW+Mnybz5z
2oQ0Tv7Gex3MrNKU/LcOqXJndTUAUpiesdUZtu14LlsdaeyHy9enb/FVhilB2D9o
ExbjKMGDVJmCSDF58LOvcnsi75+UCKFfJGAo23PqHd03Q0wrPehMlqunjCmAEkxs
JmUPwcU7n+66Y43F592hrrVTpKF/Vn4Zf+Sy8JXJ0M2ZGhDvOzMwbff6lVcB54o=
=/CJY
-----END PGP SIGNATURE-----



More information about the Linaro-dev mailing list