Closed (won't fix)
Project:
Services
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
9 Nov 2009 at 18:15 UTC
Updated:
27 Apr 2010 at 13:23 UTC
The service browser will use the first entered API key regardless of whether it has the correct domain or not. You will get the "invalid API key" message even if you have a key corresponding to the correct domain available.
The attached patch makes the service browser guess the correct key based on domain. If a key corresponding to the correct domain isn't available it will warn the user that their service browser method call probably won't work and points them to the key page.
| Comment | File | Size | Author |
|---|---|---|---|
| service_browser_key.patch | 1.73 KB | andrewlevine |
Comments
Comment #1
andrewlevine commentedforgot to mark needs review
Comment #2
marcingy commentedComment #3
andrewlevine commentedThanks for taking the time to look at this issue. Why is this behavior by design? It seems to me that this patch both reduces the probability of errors and informs the user when there are errors instead of the current behavior of just throwing an invalid API key error. It doesn't add any significant complexity to the code.
Seems like a win-win to me. What can I do to make the patch committable? Thanks
Comment #4
marcingy commentedBumping version in 6-2-x-dev this will generate an authenication failure message but the request will still be processed. Any changes will only be applied against the 6-2-x-dev version of the code. I'm tending to the view that if the browser flag is set do we infact need to run the authenication checks?
Views anyone?
Comment #5
gddPostponing for next version, its minor and I'm not horribly concerned with increasing usability in the browser honestly. It's more important to get the release out now IMO.
Comment #6
gddComment #7
gddSo it appears the Service Browser is going away in the next version. Marking won't fix.