Open topic with navigation

FAQ: Technical and OAuth

Does Photobucket provide client libraries I can use?

Why am I redirected to api###.photobucket.com when I access an album? 

How does the OAuth base-string encoding work?

What is the [identifier] in the Methods, and why does it look the way it does?

What do I do if I'm using .Net and my client is fighting me?

How do I use Web Authentication with my desktop application?

Why am I getting a"timestamp invalid -[time]" message?

Does Photobucket provide client libraries I can use?

Photobucket provides client libraries for you to use and a forum dedicated to client library support.

Why am I redirected to api###.photobucket.com when I access an album?

Photobucket separates users into ‘silos’; each one accessible by a specific number. If you check the User URLs response for a given user, you can see which sub-domains that user can be accessed by. Photobucket also provides this information in the token access responses. To access a user’s content, you must interact with that specific silo, and Photobucket provides the redirects as a convenience.

Each user and group may have a different subdomain. The subdomain is based on the album (user or group) you are accessing. This holds true for Album, Group, Media and User methods. You can get these subdomains by issuing a GET request to /album/[identifier]/url, /user/[identifier]/url, or /group/[identifier]/url, or by following and caching the redirects.

Some HTTP clients cannot handle these redirects, and Photobucket ultimately prefers that you use the information given, rather than relying on the redirects. The silo information for a user can safely be cached for a time, per user, to save calls. The silo hostnames can present a problem with OAuth signing, which requires the entire hostname and URL in the signature. For this reason, we require ALL requests, regardless of the silo being accessed, to use "http://api.photobucket.com" as the beginning of the URL being hashed in the OAuth signature process to help work around the issue of redirects and hostnames.

How does the OAuth base-string encoding work?

The OAuth basestring will look like certain parts are double encoded (mainly, the parameters to the request). This is normal, and you should not see characters other than ALPHA / DIGIT / "-" / "." / "_" / "~", and obviously the %XX characters in the encoded fields, separated by unencoded "&"

Parts:

• methodString = urlencode(method)
  • Actual HTTP method being used.
    
    For example, "GET"
• urlString = urlencode(url)
  • URL (not including query string) being accessed, no trailing slash.
    
    For example, http://api.photobucket.com/user/username/url
• for each param (name and value)
  • Push on paramArray = name+'='+urlencode(value).
    
    For example, "foo=bar%20baz"
• baseString = methodString+'&'+urlString+'&'+urlencode(join('&', paramArray))
  • For example:
    
    GET&http%3A%2F%2Fapi.photobucket.com%2Fuser%2Fusername%2Furl&format%3Dxml%26oauth_consumer_key%3D000010100%26oauth_nonce%3Dd7ehf0hdx0vhf0w%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1205433090%26oauth_version%3D1.0

Using a pre-built library from OAuth.net can do this for you.

What is the [identifier] in the Methods, and why does it look the way it does?

The [identifier] is based on the Photobucket web site URL structure:

User name > User album > Sub-album > Sub-album, etc.

The user name is ALSO the main user album name.

For example, imagine a Photobucket user, pbapi. This user has one sub-album (sub1) in the main album, and one sub-album (sub4) in album "sub1". The user has media (image1, image2, and video1) in these albums. SO:

User Name= pbapi

User Album = pbapi

Albums = sub1 and sub1/sub4

Media = image1 in pbapi, image2 in album sub1, and video1 in album sub1/sub4

To GET album "sub4" for user "pbapi", the REST path is:

/album/[identifier]

And the request is:

GET http://api123.photobucket.com/album/pbapi%2Fsub1%2Fsub4

• "123" is the silo number in which the user's media is stored (see Why am I redirected to api###.photobucket.com when I access an album)
• "pbapi" is the user name/user album
• %2F is the encoding of the slash "/"
• "pbapi%2Fsub1%2Fsub4" is the path to the user's sub4 album

Group albums have their own "group hash value" or Group ID in their URLs. The Group ID is a short, all-caps string on the URL for a group. For example, the group ID for the featured group album "Woof" is "20IF1LMOT", as displayed in the group URL:

http://gs275.photobucket.com/groups/jj285/20IF1LMOT/?featuredgroupalbum=Woof

To get media for the group album "Woof", the REST path is:

/group/[identifier]

 And the request is:

GET http://api275.photobucket.com/group/20IF1LMOT

• "275" is the silo number in which the group album is stored (see Why am I redirected to api###.photobucket.com when I access an album)
• 20IF1LMOT is the group identifier

These conventions hold true for all methods (GET, PUT, POST, DELETE), including uploads. See Conventions for more information. For an upload, the POST URL is still /album/[identifier]/upload, and a multipart request may look like http://pic.photobucket.com/dev_help/pbapi_upload.txt

What do I do if I'm using .Net and my client is fighting me?

If you have trouble accessing sub-albums, there is a known incompatibility with using the '/' character in URLs when using .NET. To help get around this, Photobucket provides Alternate Identifier Specifications to assist developers who are using .Net. See the Alternative Identifier Specifications section in the Conventions topic.

How do I use Web Authentication with my desktop application?

Open the [photobucket.com] page with the system's default http protocol handler.

• Do not enter a callback URL. Photobucket displays a page that says to close this window. Or, redirect to your own landing page that says the same thing. Show a "continue" button In your application, and exchange your tokens.
• Capture the 'end' page through a control in a manner similar to the preceding point. Do not use the default handler. Instead, use something like the Windows built-in for rendering a web page, and handle the end page.
• Register (temporarily?) a custom protocol handler, and use that as the callback (like, x-yourappname://oauth-done), which can let your program continue. This is the Photobucket preferred method.

If for any reason you cannot implement one of the preceding three suggestions (for example, you have a consumer electronics device, like a set-top box), contact Photobucket for further assistance.

Why am I getting a "timestamp invalid -[time]" message?

Important! Make sure you use UTC time for the source.

When you see a timestamp difference (the number in the message) that is greater than a few thousand, check your server's timestamp and compare it to the message. Typically, the time stamps are close or the same. A difference greater than a few thousand means the API server did not receive a proper timestamp field in your request. The difference can occur for a number of reasons:

1. Your OAuth request was not signed.
2. Your OAuth request was signed, but on a redirect (response code 301-307), your library did not resend all appropriate data. This is a common problem with POSTs. The HTTP RFC (for 30x) says that the method should be maintained for at least 301 and 307, but does not specifically state that the request payload (in the case of POST here) should also be resent. This is an ambiguity. Because the Photobucket API needs that POST payload to operate on, you MUST re-send all data on 301 and 307 response codes. For many libraries (including cURL) extra code around the built-in libraries is required for proper handling.
3. Your server's (or client's) clock is off by more than Photobucket allows. For small values of the time-delta in the exception message, this is the most likely case. You may need to use a more reliable time source to initially seed your application's time stamps. Photobucket recommends getting the time from a reliable source (such as the /time method on the Photobucket API) at the invocation of the client, calculating the delta between the reliable timestamp and the host machine's timestamp, and using that as an offset on later requests. For example, if Photobucket replies with a time of 1220566660, but your local install reports 1220561160, the difference is +5500. You can apply that difference to later operations by taking the local install's time (for example, 1220592112) and adding the offset (resulting in 1220597612) to reduce the delta between your request's timestamp and the server timestamp.

Make sure that you send all the appropriate headers (content-type, etc) so the Photobucket server knows you are sending a multipart/form-data type message. Also be sure that you have a valid mime payload. If the whole message is not formatted properly, the server may discard the payload.

Open topic with navigation