Should we allow anonymous users to pull from Zanata?

Sean Flanigan sflaniga at redhat.com
Mon Jul 28 05:19:15 UTC 2014


On 2014-07-28 14:21, Ding Yi Chen wrote:
> 
> 
> ----- Original Message -----
>> On 2014-07-25 17:04, Ding Yi Chen wrote:
>>> At this stage, you need to register to be able to pull.
>>> In other words, you need to provide zanata APIKEY in order to pull
>>> or use FAS to login and download translation.
>>>
>>> However, if allow anonymous to pull, it will benefit:
>>> 1. automatic build scripts: so developers can put their build scripts to
>>> public git.
>>> 2. Multilingual dictionary projects: so they can query zanata.
>>
>> Why can't they use API keys?
> 
> Short answer: Convenience, just like you don't need API or password
> to pull from GitHub, public website and anonymous FTP.

API keys aren't required for plain git, but github does require
authentication to use the github API (or else you are limited to 60
calls per hour, per IP).  I don't think we could afford to be that
generous to anonymous users though.

> If FAS allows packages, projects or organizations to have their own account, they can surely create an account,
> then issue the API key with the package.
> 
> Use case:
> John heard about Fedora Zanata and since Fedora contains high quality
> translation, he wants to create dictionary App using Zanata as
> backend. So what API keys should he use? John is very unlikely to use
> his personal API key.
> 

If it's a hosted webapp, why not use the developer's API key?  If not,
the app can ask the user for an API key.

Incidentally, in the case of github, you can create an API key for use
in scripts, or else an app can use OAuth.  (So instead of asking the
user for a key, you can ask them to log in to github and store the token.)

Adding OAuth support to Zanata might make a good RFE.

> 
>>> Cons:
>>> We are not able to track the usage, therefore cannot allocate resource
>>> accordingly.
>>
>> That's a big drawback.  We don't want to open the server to denial of
>> service attacks.  Zanata's rate limiting is tied to API keys.
> 
> That's indeed the big concern.
> 
> 
> Any way, I am Ok with both decision, as I do not intent to develop the dictionary project myself
> in foreseeable future.
> 
> 
>> --
>> Sean Flanigan
>>
>> Senior Software Engineer
>> Engineering - Internationalisation
>> Red Hat
>>
>>
> 


-- 
Sean Flanigan

Senior Software Engineer
Engineering - Internationalisation
Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/trans/attachments/20140728/6b3a3ff8/attachment.sig>


More information about the trans mailing list