default imageKey???

Kevin L. Kitchens

What is the default imageKey to pass in for images uploaded prior to the new system went into place?

I've tried null, "", string.empty, and even " " (5 spaces).

What do I include to get these calls to work?

devbobo

Kevin L. Kitchens wrote:

What is the default imageKey to pass in for images uploaded prior to the new system went into place?

I've tried null, "", string.empty, and even " " (5 spaces).

What do I include to get these calls to work?

Kevin,

For the moment, the best thing to do for those images is not to send the ImageKey. However, that is going to be a temporary measure as phase 3 of our security roll out is going to require those ImageKeys to be sent for all requests.

You may need to write a script to add the ImageKey for all your old images, calling smugmug.images.get for each of your albums will return the ImageKey for each image.

Let me know if you have any other questions.

David

Kevin L. Kitchens

devbobo wrote:

Kevin,

For the moment, the best thing to do for those images is not to send the ImageKey. However, that is going to be a temporary measure as phase 3 of our security roll out is going to require those ImageKeys to be sent for all requests.

You may need to write a script to add the ImageKey for all your old images, calling smugmug.images.get for each of your albums will return the ImageKey for each image.

Let me know if you have any other questions.

David

Wow... Sorry to complain, but what a stupid decision that was. Breaking backward compatibility like that.

The tool I use for the API either takes the imageKey (1.2.0) or it does not (1.1.1). Since you're requiring the imageKey for new items, I have to use 1.2.0, but for older items with no imageKey, you're saying don't send it at all -- which is not an option as the field is required.

As a developer, when you break something like that, you should always give a default value for the older images. Such as empty string or whatever. This would allow to system to continue to work unimpeded.

Very, very disappointing. I expected much better from a professional site like smugmug.

devbobo

Kevin,

Sorry that you are disapointed, however we opted for a more secure solution that prevents people from mining photos via the API simply by incrementing the ImageID. I am sure that most 3rd party developers and account holders would agree with that approach.

This rollout is been done in 3 phases to cause the least amount of grief to 3rd party developers.

FYI, both 1.1.1 and 1.2.0 accept ImageKey and AlbumKey parameters. All images both old and new have an ImageKey, you can retrieve that ImageKey for each image by calling smugmug.image.get on the album in which they are contained.

David

Kevin L. Kitchens

devbobo wrote:

Kevin,

Sorry that you are disapointed, however we opted for a more secure solution that prevents people from mining photos via the API simply by incrementing the ImageID. I am sure that most 3rd party developers and account holders would agree with that approach.

This rollout is been done in 3 phases to cause the least amount of grief to 3rd party developers.

FYI, both 1.1.1 and 1.2.0 accept ImageKey and AlbumKey parameters. All images both old and new have an ImageKey, you can retrieve that ImageKey for each image by calling smugmug.image.get on the album in which they are contained.

David

I guess I'm upset because this came totally out of the blue. I've had a smug mug account for years and an API key for quite some time. I don't know why such a major and problem causing "upgrade" was not given proper notification.

You have my email address and know my account as an API key. You can even tell that the API key is used nearly daily. It seems common sense that you would pull a list of these developers and send several email notifications.

It would have been much easier to get this resolved and start logging imageKeys well before this drastic change was implemented. We cannot all loiter around the API forum to get this sort of information.

Again, this security and image mining could also have been left optional for a period of time -- as you're doing with allowing old images to be accessed. This would have given developers the time they need to make necessary conversions.

In the future I hope smugmug will appreciate and value their customers time a little more and show a bit more consideration.

My users are aware that my site is down solely because of a bad smugmug decision. It looks a bit silly when I also refer them TO smugmug for excellent image hosting. I cannot imagine the conflict in their minds even if they never use the API.

Too late now... the damage is done. Now I have to jump through 1,000,000 hoops to try to get things back on track.

devbobo

Kevin,

These changes are being rolled out in 3 phases to allow developers time to upgrade their apps..

Phase 1: Active NOW !!
- Return AlbumKey and ImageKey information where required
- Handle errors for invalid AlbumKey/ImageKey if sent
- No other errors returned

Phase 2: TBD
- Return errors for Images or Albums (that were created after the new implemention of keys) if the ImageKey or AlbumKey parameters aren't sent or are invalid

Phase 3: TBD
- Return errors for all methods where ImageKey or AlbumKey aren't sent.

Unfortunately, due to the fact that we needed to return both ImageKey and AlbumKey, that obviously required us to modify method responses, which affected XML-RPC more than others, but was out of my control.

Perhaps you should look at using REST or JSON, not only are they easier to work with and have lighter responses...had you been using either of these the changes wouldn't have affected you.

As far as notice, there is a sticky thread at the top of this forum and emails have been sent to both of our api mailing lists.

Kevin L. Kitchens wrote:

Too late now... the damage is done. Now I have to jump through 1,000,000 hoops to try to get things back on track.

I think that you are blowing this out of proportion, as to get your site working now, you only need to be able to handle the new responses from smugmug.albums.create and the upload methods. There is no requirement at this stage to send AlbumKey or ImageKey.

David

onethumb

Kevin L. Kitchens wrote:

I guess I'm upset because this came totally out of the blue. I've had a smug mug account for years and an API key for quite some time. I don't know why such a major and problem causing "upgrade" was not given proper notification.

You have my email address and know my account as an API key. You can even tell that the API key is used nearly daily. It seems common sense that you would pull a list of these developers and send several email notifications.

It would have been much easier to get this resolved and start logging imageKeys well before this drastic change was implemented. We cannot all loiter around the API forum to get this sort of information.

Again, this security and image mining could also have been left optional for a period of time -- as you're doing with allowing old images to be accessed. This would have given developers the time they need to make necessary conversions.

In the future I hope smugmug will appreciate and value their customers time a little more and show a bit more consideration.

My users are aware that my site is down solely because of a bad smugmug decision. It looks a bit silly when I also refer them TO smugmug for excellent image hosting. I cannot imagine the conflict in their minds even if they never use the API.

Too late now... the damage is done. Now I have to jump through 1,000,000 hoops to try to get things back on track.

Hi Kevin,

This feature wasn't planned (or even, truth be told, wanted) by SmugMug, so we couldn't really give much advanced notification. We were alerted to potential privacy issues with the way we were numbering our images and had to react, for the good of our customer base, as quickly as we could.

Instead of advanced notification, we opted into giving API developers a grace period whereby the ImageKey isn't required, but is provided, giving API developers time to update their code.

We also have a "no spam" policy at SmugMug, which means different things to different people, so we're *very* sensitive about sending emails out.

We have email mailing lists set up expressly for this purpose - you can opt-in to receive email from us about the API, and we can then send you email knowing you actually want it.

Since you (apparently?) didn't sign up for either of the mailing lists, we have to assume that you didn't want to receive email from us, and thus, that we shouldn't email you.

I'm sorry if we handled this poorly, but we did our best to solicit feedback from our community and customers and react accordingly. All things considered, I'm fairly proud of the way we handled things - both speed and manner.

Thanks,

Don

Kevin L. Kitchens

onethumb wrote:

Hi Kevin,

This feature wasn't planned (or even, truth be told, wanted) by SmugMug, so we couldn't really give much advanced notification. We were alerted to potential privacy issues with the way we were numbering our images and had to react, for the good of our customer base, as quickly as we could.

Instead of advanced notification, we opted into giving API developers a grace period whereby the ImageKey isn't required, but is provided, giving API developers time to update their code.

We also have a "no spam" policy at SmugMug, which means different things to different people, so we're *very* sensitive about sending emails out.

We have email mailing lists set up expressly for this purpose - you can opt-in to receive email from us about the API, and we can then send you email knowing you actually want it.

Since you (apparently?) didn't sign up for either of the mailing lists, we have to assume that you didn't want to receive email from us, and thus, that we shouldn't email you.

I'm sorry if we handled this poorly, but we did our best to solicit feedback from our community and customers and react accordingly. All things considered, I'm fairly proud of the way we handled things - both speed and manner.

Thanks,

Don

Well Don, obviously I disagree. But emailing developers about a major, site-breaking change would be considered spam by only the most obnoxious users.

I'm not making a big deal of this as I have been down for four days.

First the upload code broke and images I uploaded after the unnotified change resulted in images that could not be seen, because I didn't have the full imageID_imageKey filename. So while the old upload code worked fine, the image could not be seen because I was only storing the ID -- had no idea Key even existed.

Secondly, I rely on the imageinfo to determine height or width. That was not accessible without the key. But to do that, I had to switch to 1.2.0 which broke a host of other things from 1.1.1.

Now, as I muddle through getting all this back up and running, I learn that no consideration was given to make this change backwards compatible. Older images are going to soon be broken with phase 3 as I'll have to dig up and match imageKeys to over 5000 images. The 1.2.0 document is poor at best and I'm working through that as well.

Again, it's too late now. The damage has been done all for something that should have been a user option to tighten security. At least on older folders.

I'm worn out from trying to fix this and explaining this over and over and over as I fix one thing and create 10 new issues.

Kevin L. Kitchens

devbobo wrote:

Kevin,

Sorry that you are disapointed, however we opted for a more secure solution that prevents people from mining photos via the API simply by incrementing the ImageID. I am sure that most 3rd party developers and account holders would agree with that approach.

This rollout is been done in 3 phases to cause the least amount of grief to 3rd party developers.

FYI, both 1.1.1 and 1.2.0 accept ImageKey and AlbumKey parameters. All images both old and new have an ImageKey, you can retrieve that ImageKey for each image by calling smugmug.image.get on the album in which they are contained.

David

Documentation for 1.2.0 claims smugmug.images.get will return an array of int[], but I get an error saying a struct is expected. Which makes sense since I'm supposed to be able to get the imageKey out of all this.

devbobo

Kevin,

I don't understand why you think you need to upgrade to 1.2.0 ? You don't, 1.1.1 should work fine for you...and you are probably making a lot of additional work by doing so, since the response formats changed by 1.1.1 and 1.2.0

Additionally, ImageKey isn't currently required to be sent to smugmug.images.getInfo.

Kevin L. Kitchens

devbobo wrote:

Kevin,

I don't understand why you think you need to upgrade to 1.2.0 ? You don't, 1.1.1 should work fine for you...and you are probably making a lot of additional work by doing so, since the response formats changed by 1.1.1 and 1.2.0

Additionally, ImageKey isn't currently required to be sent to smugmug.images.getInfo.

Somehow the other night when the upload was failing, we said I needed to do 1.2.0 to get the imageKey returned.

devbobo

Kevin L. Kitchens wrote:

Somehow the other night when the upload was failing, we said I needed to do 1.2.0 to get the imageKey returned.

I just looked through my responses to that thread and there is no mention of 1.2.0.

Kevin L. Kitchens

devbobo wrote:

I just looked through my responses to that thread and there is no mention of 1.2.0.

The confusion there came from the new imageKey being appended to the filename and I needed that key to get it. The 1.1.1 documentation does not list the imageKey being returned with the upload repsonse and the 1.2.0 documentation does list it. There were no "imageKey" is not needed discussions for the other methods that night.

All I knew is that because smugmug was adding the _#@$%! to the filename and I had to have that to show the image, the only way the documentation showed me able to get that was via 1.2.0 or greater.

Once I went there, there was no going back... Until tonight you tell me that I don't need the other for the other methods.

Now I'm hoping I can rollback my API class and get back on track.

Documentation needs a once-over as well it would seem.

devbobo

Kevin L. Kitchens wrote:

Documentation needs a once-over as well it would seem.

I'm in the process of rewriting a lot of documentation for the wiki, but it's a slow process.

Kevin L. Kitchens

devbobo wrote:

I'm in the process of rewriting a lot of documentation for the wiki, but it's a slow process.

Back up now. Rolled back to the old API 1.1.1 and only made the changes needed to capture the ID and Key on upload so I can properly show the image.

devbobo

Kevin L. Kitchens wrote:

Back up now. Rolled back to the old API 1.1.1 and only made the changes needed to capture the ID and Key on upload so I can properly show the image.

seems to be working now ?

Kevin L. Kitchens

devbobo wrote:

seems to be working now ?

Just to let you guys know, I do appreciate the hardwork you do and still prefer smugmug over the other guys. My beef was with the communication and information provided only.

Now that I can breathe a day or two, I will look into changing to another API flavor. Until then, thanks again.

devbobo

Kevin L. Kitchens wrote:

Just to let you guys know, I do appreciate the hardwork you do and still prefer smugmug over the other guys. My beef was with the communication and information provided only.

Now that I can breathe a day or two, I will look into changing to another API flavor. Until then, thanks again.

Glad you got back up and running... sorry that it took so long.

You can sign up to the API mailing lists here, if you haven't already.

Cheers,

David