It appears that photo links are now only visible if logged in. This is a change and a highly unfortunate one for us, as we have put thousands of image links into our websites. We now have three very broken websites. We also have put thousands of image links into OpenStreetMap tagged as image, a laborious process to be sure. Now, to our dismay, everyone must log in to see our Kobo hosted images. We did not want these to be private.
While we are looking into moving the photos, this is a major pain. I wondered if 1) am I correct this is an intentional change and there’s no way it will go back? or 2) is there a possibility to make it optional whether your photos are behind logins or open? Can this be a feature? We do find the Kobo hosting very useful. We are under the humanitarian hosting.
@Kal_Lam I’m having the same issue as the original poster. I’m the web developer for a citizen program that use Kobo to collect data and photos from our users. The site as been around since Jan 2018. I used to be able to show images taken using Kobo on my site. Then this summer the images stopped working on my site.
If I log into Kobo, then I can see the image on my site and view the image from kc.kobotoolbox.org link. If I’m not logged into Kobo, I get a 403, strict-origin-when-cross-origin error
on my site and a “Not shared.” message when viewing kc.kobotoolbox.org link.
I’m assuming Kobo changed the file permission this summer. While I could download the photos from kobo, and upload them to my own S3 account, that would cause a disconnect from the attachment metadata stored in kobo and the file location on my own s3 account.
Welcome to the community! I have reported the issue with our developers so that they could have a look at what went wrong. Thanks for updating us the issue!
@wykhuh Could you confirm if you are sharing the data of this project publicly? The link you shared gives a Not shared. response, which is normal for media (or data) from a project that is not set to be publicly accessible.
Hi, this indeed is the issue but we have other data we cannot make public. The photos, however, used to be public to those who had the exact link (not really easy to find anyway so it’s de facto private unless you publicize it yourself, as we have done).
I believe they were switched to be login viewable only. The advice I got from Kobo was to make our entire project public. That is not an option for us.
I strongly suggest they either make the photo links default public and ADD A PRIVATE OPTION, or else the reverse, make them default private but allow us to make them public. It’s unfortunate it’s broken a few websites now which we built around what we thought was solid Kobo technology but that Kobo felt was not and changed it.
Hi, see my comment and you’ll know that indeed it’s been changed this summer. I’m not sure if you also cannot make your entire data set public, but in our case we cannot therefore we’re looking into moving all the photos, but it will be quite a lot of work for us.
At the moment you can only make your data either public or private, and that goes for all data (whether images or otherwise). If it was possible to access images with their direct URLs without being signed in and without data being shared publicly, then this was a bug that has been fixed.
KoBo is not an image hosting platform–integrating images publicly on other websites could result in significant costs for data transfer.
You need to download data (using the ZIP export or via the API or via a tool like DownThemAll) and then integrate it on your own site.
Either way it might have been nice to have a heads up on this so that we did not go with three broken websites all of a sudden. I am sorry there is no way to have some data public and some private. This seems like a good feature for other needs as well.
I totally agree, that would be a great feature to have for a lot of use cases. Please feel free to sketch out how you think this could work in the Suggestion Box, and maybe we can work on getting funding for such a feature in the future.
For anyone affected by this bug being fixed (which allowed publicly hosting images from KoBo), I suggest downloading your pictures through the regular way (or using the API) and uploading them to another server, e.g. Dreamhost, Amazon Web Services, or even Dropbox.
Good to know that previous behavior of letting non-logged in users access the photos was a bug on Kobo’s part and that bug has been fixed. Unfortunately, two organizations built sites around this previously accepted behavior. Now these two organizations have to spend time and money to accommodate the new behavior.
I understand that changes in data access and APIs are a normal part of the development cycle. Unfortunately, organizations with limited resources and money can find it difficult to update their sites to accommodate these changes.
I wonder if there is better way for Kobo to implement changes that directly affect how third party sites access Kobo data that would minimize the disruption to both Kobo and the other third party sites. For instance, other data providers make announcement ahead of time about breaking changes so 3rd party users can make the needed adjustments on their end before the data provider implements the changes.
I hear you @wykhuh. The main issue here is that this was a bug that was just not noticed and fixed for a really long time. Without this delay, none of this would have happened. In this case the bug fixed in April 2019 and the fix deployed to the OCHA server.
I can see how useful it is to use Kobo to host image data for integration on other sites, but the fact that this was possible without authentication and without publicly sharing the data [though you had to know the unique IDs involved] was simply a bug, and we don’t normally warn users before we deploy bug fixes.
We generally issue notifications in the app a few days before a release to inform users about new features and bug fixes to be deployed. Sometimes bug fixes get deployed in between releases as well to respond to issues as quickly as possible.
It would be great to have a general discussion about the ideal procedure for informing users about pending deployments, enhancements, new features. Please feel free to start a new topic, I think that would be a very useful discussion many others would be interested in. Thanks!
What would be really great if someone could write a small script that uses the API to pull all images (with proper authentication) and pushes them to a proper image hosting location (e.g. AWS S3 or even Github) on a regular basis.
This can be done through the API by pulling each download_url (or the filename with the proper prefix, see below) from the submission view of a project (with media), before pushing it to the right location.
curl -X GET https://kobo.humanitarianresponse.info/assets/<kpiAssetID>/submissions.json -H 'Authorization: Token <apitoken>'
This will give you your project data in JSON format, like this:
The download_url in this example will work. However, for older images (pre August 2019) you will see a (broken) URL pointing to AWS S3. This URL will be bulk updated for all projects in the coming weeks (see this PR on GitHub). So the safe way in the meantime would be to use use
https://kc.kobotoolbox.org/media/original?media_file= and add <filename> for each _uuid.
Then I wrote another script that would grab all the data submitted for a particular project using the id returned from the first script https://kc.kobotoolbox.org/api/v1/data/123. The script then looks for images the “_attachments” field.
In the new API, what does <kpiAssetID> refer to? The project id?
@wykhuh The <kpiAssetID> refers to the uid for each project (asset) in http://kf.kobotoolbox.org/assets. It is also the ID shown in the browser when using the UI:
The API works with the same parameters as before; these two request URLs will show the same results (when used for the same project):
Hello @tinok , Is this implementation a cron job? I am planing to implement this using django-cron’s, or could I also implement it using using regular python
