Currently difficulties in project exports are:
It should be possible to automate a project export with a script, with minimal difficulty.
Use API to trigger export, use API to poll for status & get filename (full connection path?).
Goal: have a script (or use a utility like curl-oauth to avoid the oauth complexities and be able to do it all in a shell script) to hit the new API to start an export. Then check the new export status API until the export is no longer busy, then the script can download the file.
The forge-classic and sfx changes are for adding the OAuth account menu item, because the third-party apps section was removed from Subscriptions and integrated into the improved OAuth page.
I like it. I have a lot of feedback though:
Being picky since security is important
Can we provide a sample shell script that uses the API? We also need to document the API. Particularly note the http codes, e.g. so people know 503 means task busy not server having problems.
ProjectAdminRestController._check_security checks for read so that the export status check doesn't have to be authenticated. But, I guess if the script that queued the export is already authenticated, re-using the auth for the status check isn't a big deal.
I noticed the body of the 403 page but I have no idea how that's happening, as I'm just raising a standard HTTPForbidden exception. Maybe I should return None like the other parts of that method do, but that just allows anon access with no error indicating that the auth failed (unless anon is disallowed later on).
The name=request_token.name was a part of a rolled-back change, and should have been removed.
Yeah, I think it's safer to require 'admin' for that whole controller
403: Right, certainly unrelated code causing that. I guess see if its a quick fix? If not, ticket up with what you did find out.
Changes pushed to allura:cj/6692
[d6d1e6] removed the revoke_oauth method and its functional test. But it's still referenced by OAuthRevocationForm
What about these items from my previous comments?
I forgot to mention: with the change to _check_security, the 302/403 issue resolved itself.
allura:cj/6692 (rebased and force-pushed)
Oh, I was wrong, but I was able to fix it.
Not exactly sure what you mean by "even more tests." Allura/allura/tests/functional/test_auth.py:TestOAuth already has functional tests of all the functionality on the /auth/oauth page, and I converted the valid case of the bearer token tests to a functional (non-mocked) test. Are you suggested we add tests to cover the interactive oauth process?
Log in to post a comment.