Posted by andrewlevine on November 9, 2009 at 6:15pm
Jump to:
| Project: | Services |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
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.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| service_browser_key.patch | 1.73 KB | Idle | FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch service_browser_key.patch. | View details | Re-test |
Comments
#1
forgot to mark needs review
#2
#3
Thanks 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
#4
Bumping 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?
#5
Postponing 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.
#6
#7
So it appears the Service Browser is going away in the next version. Marking won't fix.