Lucas_Werkmeister_WMDE added a comment.
I’ve also started to document the project under wikitech:Nova Resource:Openrefine.TASK DETAILhttps://phabricator.wikimedia.org/T194767EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Abbe98,
Lucas_Werkmeister_WMDE added a comment.
Okay, I started setting up the server and OpenRefine is running. I haven’t set up any proxy yet, so for now you can only test it via SSH proxy:
ssh -L :localhost: openrefine01.eqiad.wmflabs
@Pintoch can you see if you’re able to access the server?
Lucas_Werkmeister_WMDE added a comment.
Authentication now subject of OpenRefine/OpenRefine#1612.TASK DETAILhttps://phabricator.wikimedia.org/T194767EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lucas_Werkmeister_WMDECc: Abbe98, Pintoch,
Lucas_Werkmeister_WMDE added a comment.
Perhaps you could use an owner-only consumer for default installations? Those are tied to a single account and don’t need confirmation, so I think it might be possible to request them automatically (but I’m not sure if that’s a good idea).TASK
Pintoch added a comment.
When running software on localhost, the client needs to have OAuth consumer credentials, which are supposed to be private. If I apply for an OAuth consumer for OpenRefine, I cannot put the credentials in OpenRefine's source code, because it would allow anyone to reuse them
Lucas_Werkmeister_WMDE added a comment.
Yeah, that’s going to be tricky… for a first version it might be easiest to completely disable Wikidata authentication, so that users have to use QuickStatements instead :/
To clarify – the problem is not that the server needs to do the edits (which should
Pintoch added a comment.
Note to self: for this we would need to rethink Wikidata authentication in OpenRefine, migrating it to OAuth. This would include adding OAuth support in Wikidata-Toolkit. This has not been done yet because OAuth is not suited for open source software that is run directly
