On Fri, 3 Feb 2017, at 11:16 AM, Bryan Davis wrote: > I would use a tool specific database table [0] rather than the local > files system mostly to avoid using NFS to save state. Otherwise this > is not a horrible practice. The token that your app receives is only > valid in combination with the app's secret key. You should do anything > you can to prevent it from being leaked to other users of the > application as that would allow them to impersonate the true owner. > Storage in a database table that is owned by your tool and not > readable by other tools or as you are doing in a file if that file is > not world readable are reasonable precautions. Fundamentally you > should treat the user's OAuth token the same way you would treat the > password for a bot account or any other authentication secret. >
Yes, I wondered about a database. I went with a file because the processing will be done completely within one process and the token file (and all other job-processing files) are deleted at the end of that process. The file itself is written by the web server user (which is always the same as the tool account isn't it?) and then chmod'd 0660. Is that enough? And as for telling the user about what's going on, there's a message: " Note that for JP2 and PDF, your authentication credentials will be stored on the Tool Labs server for as long as it takes to complete the conversion (usually less than an hour)." See it at: http://tools.wmflabs.org/ia-upload/test/commons/fill?iaId=cu31924022189587&commonsName=test Is that clear enough? Should it link to somewhere? Thanks for your help! —sam _______________________________________________ Labs-l mailing list Labs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/labs-l
