ckan / ideas

[DEPRECATED] Use the main CKAN repo Discussions instead:
https://github.com/ckan/ckan/discussions
40 stars 2 forks source link

Return extension metadata when calling Status API #179

Open jqnatividad opened 8 years ago

jqnatividad commented 8 years ago

It would be nice if we can also get metadata (version no, etc.) when calling /api/util/status.

Also would be nice if it can show all the valid API endpoints for that CKAN instance.

torfsen commented 8 years ago

Good idea. It would be nice if extensions could provide their own metadata for that.

davidread commented 8 years ago

I am slightly uncomfortable with how revealing it is already tbh. I think we need to be careful what is there by default.

It's frowned upon to reveal version numbers due to security. Of course it is obscurity, but there is no point making it easier for hackers to identify unpatched CKANs. What benefit did you envisage?

torfsen commented 8 years ago

@davidread Fingerprinting will always allow you to identify that information, so you're gaining little by hiding it.

On the other hand any piece of code that uses API functions introduced by extensions could benefit from it by making sure that they're talking to the right version or by adding version-specific code to support multiple versions.

davidread commented 8 years ago

@torfsen of course it's not a high barrier, but it makes it harder, and I believe it's best practice not to reveal say your php or apache version to the internet.

Perhaps the compromise would be to advertise an extension's API version? That way the majority of extensions which don't have an API are unaffected.

torfsen commented 8 years ago

@davidread That sounds like a good compromise and would cover the use cases that I have in mind.

jqnatividad commented 8 years ago

It'd be easier to have CKAN-aware sites/apps work with disparate installations managed by different parties.

With installations we're helping with, it will also help with management issues if we can automagically catalog the metadata about the installation as well, and it would be a requirement for a "CKAN Multiple Instance/Party Administration" extension, and perhaps, the extended metadata will only be exposed to API calls with a sysadmin API key (for starters, and maybe even introduce a new "application" role, as you don't necessarily want to give sysadmin to third-parties)

Maybe we can start with the compromise @torfsen, @davidread first and iterate from there?

torfsen commented 8 years ago

Sounds like a good idea, @jqnatividad. In the long term I'd love to see a built-in CKAN extension manager where I can install, update, configure and uninstall extensions. That would require quite some more work, but anything that makes (automatic and manual) installation of extensions easier gets my vote.

davidread commented 8 years ago

Yes, all sounds good to me. I'll stay out of it now my concern about authorization are being considered.

wardi commented 8 years ago

How about returning the commit id for ckan and github URL and commit id for every extension installed when they can be determined? I've wanted to verify the running versions of things more than once.

Any additional data returned from status_show should require an extra parameter, such as include_commit_ids=True. I'm on the fence about making returning the commit ids sysadmin-only. It's possible that pretty much every ckan site is violating the AGPL by not providing this information.

davidread commented 8 years ago

Is this the clause you're referring to?

  • d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work.

So you can't remove the ability to download the source that is running, but we don't currently include it, I guess?

wardi commented 8 years ago

@davidread yeah, sounds like there's no violation right now but if we do add this feature then users might be in violation if they remove it.

amercader commented 8 years ago

@wardi not sure if this is exactly what you mentioned but I wrote this a while ago: https://github.com/ckan/ckanext-repo

It just shows the last commit on the frontend but it would be trivial to wrap it into an action (or extend status_show)

wardi commented 8 years ago

@amercader that's great! I wonder how I missed that.