-----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----- _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
