I am not sure why you are not using the more common "authorize_url" parameter in the request token to expose where we need to connect to.
The following snippet of code (in ruby using the oauth gem) works for every other oauth site we've coded for:
And you should end up with the url to redirect users to.
Here we end up with:
"http://openapi.lovefilm.com/oauth/authorize?oauth_token=xxxxx"
When in fact we need to connect to:
"https://www.lovefilm.com/authenticate?oauth_token=xxxxx"
This is a bit of a pain as it means that we have to 'hard code' in 'https://www.lovefilm.com/authenticate' into the code as there is no way to pull it out dynamically (meaning that if you change where we connect to we have to redploy the code).
Also, as I am sure you know, https://www.lovefilm.com/authenticate seems to have a self-signed certificate. At least that is what wget is reporting.
Our certificate is a wildcard issued to "*.lovefilm.com" by the root authority "Thawte Premium Server CA" (Thawte Consulting cc). Perhaps there is a problem with your installation of wget, or it's not seeing an up to date list of certificate authorities?
A normal OAuth conforming service advertises a fixed URL for user authorisation. Note that there is no necessary relationship between this URL, and the URLs for the "Request Token" and "Access Token" requests. See:
In our case, we specify "https://www.lovefilm.com/activate".
As a convenience to avoid having to redeploy code if the authorisation URL changes, you can simply retrieve it from the additional parameter "login_url" supplied in the response to /oauth/request_token. A conforming OAuth library should be able to report such additional parameters as specified here:
If your library cannot do this, you can just fall back to the standards conforming fixed URL mentioned above. If this URL every changes, we will not 404 the old one, but instead issue an HTTP redirect (in fact you may have noticed that we already do this).
This is all explained at "http://developer.lovefilm.com/docs/api_overview/Accessing_the_API#config":
> User Authorisation URL
>
> Returned in the login_url parameter in the request_token response
> data. If your library does not expose this information, please use
> "https://www.lovefilm.com/activate"
>
> Note: As per Section 6.2.1 of the OAuth specification, you should take
> the token (but not the secret) returned by your initial call to Request
> Token, and append it the User Authorisation URL in the "oauth_token"
> query parameter. E.g. if you received the token "XYZZY", you should
> direct the user to "https://www.lovefilm.com/activate?oauth_token=XYZZY".
>
> If you do not do this, the user will be prompted to enter the token
> manually (referred to in our UI as the "Activation Code"). In this case
> you must make sure you display the token to the user first.
Ampersands certainly should be encoded as entities as you suggest, and that is what I am seeing in my testing. Please can you provide me with an example HTTP request / response pair exhibiting this problem. E.g. this is what I see:
GET http://openapi.lovefilm.com/catalog/title?term=star+wars
Authorization: OAuth oauth_consumer_key="myconsumerkey",oauth_nonce="e1892027a065282f41b98a",oauth_signature="%2B3bmd77SO6eZR21F8Fr7oCvJ0a0%3D",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1266408070",oauth_version="1.0"
User-Agent: libwww-perl/5.805
200 OK
Connection: close
Date: Wed, 17 Feb 2010 12:01:10 GMT
Accept-Ranges: bytes
Server: Apache
Vary: Accept-Encoding
Content-Length: 40853
Content-Type: application/xml;charset=UTF-8
Client-Date: Wed, 17 Feb 2010 12:01:11 GMT
Client-Peer: 79.125.14.213:80
Client-Response-Num: 1
X-Lighty-Magnet-Uri-Path: /catalog/title
X-Mashery-Responder: proxyworker-eu-i-c76f66b3.mashery.com
I'd copied & pasted the XML to a local file from Firefox's xml viewer instead of copying the source.
Firefox converts the & to &
I'm having to copy the XML to local files at the moment because I'm getting a 401 Invalid Signature error when I call the api with a signed url from QtWebKit. (built on webkit)
The signed url works fine in a webkit browser like Google Chrome.
We've made a few changes to the API recently, the majority of which are backwards compatible if you're using it correctly. One exception to this is the handling of the 'refine' parameter. We'll be uploading a newer set of documentation soon in the next couple of days, so please check back then.
In the meantime, please try 'refine=hotlist' instead.
I having issues geting the requestToken URL call to work through the JavaScript oauth implementation using an AJAX request. I've set up the oAuth service configuration as specified in the 'Accessing the API' and while the request makes it so the server ok the response from the server is 501 - Not Implemented. Is there any obvious reason for this?
Yes. When it comes to the user-authorisation step, your application will need to activate the user's web-browser with the relevant authorisation URL and token. Once they user has authorised the app they will need to note down the verification code, switch back to the windows application, and enter the verification code.
yes - finally managed to work through how to use the refine parameter. The documentation is perhaps not easy to understand.
Use
GET /catalog/title?refine=all
to get a list of links that you can use to refine your search results. You can add the other arguments as needed.
These links are returned this way in between <search> tags.
<catalog><link href="...." title="Certificates"><link href="..." title="U" /></link></catalog>
each facet that you can filter by is the top level link - e.g. Certificates and the child links are what you can refine by U, UA, 12A etc.
Use those links to refine your results. For example the link to get new releases is:
GET /catalog/titles?f=hotlist%7Cnew_releases
and that for most popular titles is:
GET /catalog/titles?f=hotlist%7Cmost_popular
replace "hotlist" with a different facet and the "new_releases" with an available filter to get filter specific titles. I think the recommendation would be to use the refine=all argument to get all possible alternatives instead of hardcoding the above values.
Message edited by Alasdair McIntyre 3 years ago
Phil Smy – 3 years ago
I am not sure why you are not using the more common "authorize_url" parameter in the request token to expose where we need to connect to.
The following snippet of code (in ruby using the oauth gem) works for every other oauth site we've coded for:
@consumer=OAuth::Consumer.new key, secret, {:site => "http://openapi.lovefilm.com"}
@request_token=@consumer.get_request_token
@request_token.authorize_url
And you should end up with the url to redirect users to.
Here we end up with:
"http://openapi.lovefilm.com/oauth/authorize?oauth_token=xxxxx"
When in fact we need to connect to:
"https://www.lovefilm.com/authenticate?oauth_token=xxxxx"
This is a bit of a pain as it means that we have to 'hard code' in 'https://www.lovefilm.com/authenticate' into the code as there is no way to pull it out dynamically (meaning that if you change where we connect to we have to redploy the code).
Also, as I am sure you know, https://www.lovefilm.com/authenticate seems to have a self-signed certificate. At least that is what wget is reporting.
Alasdair McIntyre – 3 years ago
Our certificate is a wildcard issued to "*.lovefilm.com" by the root authority "Thawte Premium Server CA" (Thawte Consulting cc). Perhaps there is a problem with your installation of wget, or it's not seeing an up to date list of certificate authorities?
A normal OAuth conforming service advertises a fixed URL for user authorisation. Note that there is no necessary relationship between this URL, and the URLs for the "Request Token" and "Access Token" requests. See:
"http://oauth.net/core/1.0#rfc.section.4.1"
"http://oauth.net/core/1.0#rfc.section.4.2"
In our case, we specify "https://www.lovefilm.com/activate".
As a convenience to avoid having to redeploy code if the authorisation URL changes, you can simply retrieve it from the additional parameter "login_url" supplied in the response to /oauth/request_token. A conforming OAuth library should be able to report such additional parameters as specified here:
"http://oauth.net/core/1.0#rfc.section.6.1.2"
"http://oauth.net/core/1.0a#rfc.section.6.1.2"
If your library cannot do this, you can just fall back to the standards conforming fixed URL mentioned above. If this URL every changes, we will not 404 the old one, but instead issue an HTTP redirect (in fact you may have noticed that we already do this).
This is all explained at "http://developer.lovefilm.com/docs/api_overview/Accessing_the_API#config":
> User Authorisation URL
>
> Returned in the login_url parameter in the request_token response
> data. If your library does not expose this information, please use
> "https://www.lovefilm.com/activate"
>
> Note: As per Section 6.2.1 of the OAuth specification, you should take
> the token (but not the secret) returned by your initial call to Request
> Token, and append it the User Authorisation URL in the "oauth_token"
> query parameter. E.g. if you received the token "XYZZY", you should
> direct the user to "https://www.lovefilm.com/activate?oauth_token=XYZZY".
>
> If you do not do this, the user will be prompted to enter the token
> manually (referred to in our UI as the "Activation Code"). In this case
> you must make sure you display the token to the user first.
Richard Carter – 3 years ago
I'm having problems calling the games catalog and filtering to only return Xbox 360 games
I can filter for PS3 and Wii games.
I've tried,
/catalog/games?format=xbox 360
/catalog/games?format=xbox+360
/catalog/games?format=xbox%20360
and
/catalog/games?refine=xbox 360
/catalog/games?refine=xbox+360
/catalog/games?refine=xbox%20360
/catalog/games?format=PS3 // <-- works fine
Am I missing something really obvious?
Alasdair McIntyre – 3 years ago
You're not doing anything wrong. There is currently a problem with spaces in catalogue filters. We have a fix for this, due for publish on Monday.
Richard Carter – 3 years ago
Thanks for the quick response on my previous question.
I've having a problem with some of the xml being returned.
The xml parser I'm using throws an error when it comes across the following line of xml,
<link href="http://openapi.lovefilm.com/catalog/film?start_index=1&term=star+wars" rel="self" title="self"/>
The & in the href value is the problem.
Correct me if I'm wrong but shouldn't this be encoded as &
Looking at a Google base feed, they encode their url values.
<link rel='self' type='application/atom+xml' href='http://www.google.com/base/feeds/snippets?q=9780596101992&start-index=1&max-results=25'/>
Alasdair McIntyre – 3 years ago
Ampersands certainly should be encoded as entities as you suggest, and that is what I am seeing in my testing. Please can you provide me with an example HTTP request / response pair exhibiting this problem. E.g. this is what I see:
GET http://openapi.lovefilm.com/catalog/title?term=star+wars
Authorization: OAuth oauth_consumer_key="myconsumerkey",oauth_nonce="e1892027a065282f41b98a",oauth_signature="%2B3bmd77SO6eZR21F8Fr7oCvJ0a0%3D",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1266408070",oauth_version="1.0"
User-Agent: libwww-perl/5.805
200 OK
Connection: close
Date: Wed, 17 Feb 2010 12:01:10 GMT
Accept-Ranges: bytes
Server: Apache
Vary: Accept-Encoding
Content-Length: 40853
Content-Type: application/xml;charset=UTF-8
Client-Date: Wed, 17 Feb 2010 12:01:11 GMT
Client-Peer: 79.125.14.213:80
Client-Response-Num: 1
X-Lighty-Magnet-Uri-Path: /catalog/title
X-Mashery-Responder: proxyworker-eu-i-c76f66b3.mashery.com
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<search>
<total_results>75</total_results>
<items_per_page>20</items_per_page>
<start_index>1</start_index>
<link href="http://openapi.lovefilm.com/catalog/title?start_index=1&term=star+wars" rel="self" title="self"/>
<link href="http://openapi.lovefilm.com/catalog/title?start_index=21&term=star+wars" rel="next" title="next"/>
<link href="http://openapi.lovefilm.com/catalog/title?start_index=61&term=star+wars" rel="last" title="last"/>
<catalog_title>
<studio>WARNER HOME VIDEO</studio>
<release_date>2008-12-08</release_date>
<production_year>2008</production_year>
<number_of_ratings>10089</number_of_ratings>
...
</xml>
Richard Carter – 3 years ago
Sorry my mistake.
I'd copied & pasted the XML to a local file from Firefox's xml viewer instead of copying the source.
Firefox converts the & to &
I'm having to copy the XML to local files at the moment because I'm getting a 401 Invalid Signature error when I call the api with a signed url from QtWebKit. (built on webkit)
The signed url works fine in a webkit browser like Google Chrome.
Richard Carter – 3 years ago
Could I have an example of how to use the refine parameter for a catalog search.
I've tried,
/catalog/film?refine=coming_soon
/catalog/film?refine=most_popular
/catalog/film?refine=new_releases
All return the same results as /catalog/film so I guess using it correctly.
I couldn't find any examples using the refine parameter in the API docs.
Alasdair McIntyre – 3 years ago
We've made a few changes to the API recently, the majority of which are backwards compatible if you're using it correctly. One exception to this is the handling of the 'refine' parameter. We'll be uploading a newer set of documentation soon in the next couple of days, so please check back then.
In the meantime, please try 'refine=hotlist' instead.
eggbomb – 3 years ago
I having issues geting the requestToken URL call to work through the JavaScript oauth implementation using an AJAX request. I've set up the oAuth service configuration as specified in the 'Accessing the API' and while the request makes it so the server ok the response from the server is 501 - Not Implemented. Is there any obvious reason for this?
Andrew Barlow – 3 years ago
If you could post URL for a zip of any relevant code, I may be able to help you there! I had similar issues for a while, but have since cracked them.
misamae – 3 years ago
Hi,
Using the OAuth methods, is it possible to develople a windows client for lovefilm?
Thanks, Meisam.
Alasdair McIntyre – 3 years ago
Yes. When it comes to the user-authorisation step, your application will need to activate the user's web-browser with the relevant authorisation URL and token. Once they user has authorised the app they will need to note down the verification code, switch back to the windows application, and enter the verification code.
willj – 3 years ago
You mention above changes to the refine parameter for catalog requests, has the documentation been updated?
I'm still unsure how this is used, I've tried the following but get the same (very old) results for each.
/catalog/title?refine=most_popular
/catalog/title?refine=new_releases
/catalog/title?refine=hotlist
Thanks.
willj – 3 years ago
Just a small bump - I'm still having issues with the refine parameter.
Has anyone managed to get it working?
pani – 3 years ago
no - not working yet from what I can gather.
pani – 3 years ago
yes - finally managed to work through how to use the refine parameter. The documentation is perhaps not easy to understand.
Use
GET /catalog/title?refine=all
to get a list of links that you can use to refine your search results. You can add the other arguments as needed.
These links are returned this way in between <search> tags.
<catalog><link href="...." title="Certificates"><link href="..." title="U" /></link></catalog>
each facet that you can filter by is the top level link - e.g. Certificates and the child links are what you can refine by U, UA, 12A etc.
Use those links to refine your results. For example the link to get new releases is:
GET /catalog/titles?f=hotlist%7Cnew_releases
and that for most popular titles is:
GET /catalog/titles?f=hotlist%7Cmost_popular
replace "hotlist" with a different facet and the "new_releases" with an available filter to get filter specific titles. I think the recommendation would be to use the refine=all argument to get all possible alternatives instead of hardcoding the above values.
willj – 3 years ago
Brilliant, good work pani!
I'll see if I can find some time to test it later.
Thanks :)