Forums | Admin Discussion Forums: open-discussion Start New Thread Nested Flat Threaded Ultimate Show 25 Show 50 Show 75 Show 100   By: Tom Copeland RE: Public (unauthenticated) API [ reply ]   2009-10-07 15:43 Hi James - Yeah, maybe we can just do that. We're only getting a hundred or so API requests a day, and I could still create an ApiRequest record but just leave user_id as nil. OK, I've put that on my TODO list, and I'll post back here when it's done. FWIW, the GForge code that we're using is all here: http://support.rubyforge.org/svn/trunk/support/gforge402/ It's all PHP and it's all somewhat, well, PHPy. Yours, Tom By: James Tucker RE: Public (unauthenticated) API [ reply ]   2009-10-05 10:00 That would work just fine for my use case (read operations being unauthorized), indeed I was only suggesting read side operations. Another possible option is to provide a 'user account' which is 'public domain', allowing access to some (read only) subset of the API. This is a slightly more complex idea, as fundamentally it'll introduce some notion of "roles", however, there is some of this notion already existing in who is allowed to create files on packages - it may be sufficient to just create a dummy account with no packages / projects. At this time I can't be sure, not having looked at the code from this angle / not knowing the code base / gforge so well. By: Tom Copeland RE: Public (unauthenticated) API [ reply ]   2009-10-05 01:36 Hi James - Thanks again for the patch. Hm, so far I figured all API access would be via basic auth; that way we could flag API abusers. Hm... maybe we could add a /packages/releases/most_recent API endpoint that wasn't protected? Or maybe all read operations could be unauthorized? Anyone else have thoughts on that? Thanks, Tom By: James Tucker Public (unauthenticated) API [ reply ]   2009-10-04 01:30 I'm writing a new installer for rubygems that will operate via a web hosted script. The plan / intent is to provide a `ruby -ropen-uri -e ...` approach, suitable for very easily working around issues like the 1.2 upgrade bug. In order to make such a script easy to use, it shouldn't require rubyforge credentials, however, I have a requirement to 'discover' the 'latest released .tgz file'. I could add a task to rubygems rake files which publishes a simple text file containing the name, however, even with this information, I still need to discover the impractical path that gforge uses for placing files. The patch of mine Tom deployed today provides the ability to discover this location; example (from my small api wrapper i'm using in irb): latest_rubygems_files = rf.files(rf.latest_release_id(rf.package_id('rubygems'))) latest_rubygems_tgz = latest_rubygems_files.find { |f| f['frs_file']['filename'] =~ /\.tgz$/ } Using the above I can now generate the correct download url. I would however like as I say to able to perform this path of discovery without http basic auth requirements. I'm happy to provide patches toward this, but first I need to know if opening up a non-auth API is desired / part of the project goals.