Treat 403 errors differently when due to lack of API support or API request limit exceeded #29
Comments
|
Adding some context: Availability of API access is one qualifier. I believe the availability of the service (OAuth) should be one too. Getting the user the pointed message about how to solve the problem is critical. 'User not authenticated' is too broad and forces the user to re-try with no success and causes developers to question their code unnecessarily. Improving the error messages to : 'OAuth services unavailable, please check trust-site (?) for status', or 'API services not available for your Edition' etc. would be mush appreciated. |
|
@pbrondum Salesforce will tell us, in the error message field returned in addition to the 403 status code, that the API is not enabled for the org. But other root causes for a 403 error should probably force a re-login, which Swiftly Salesforce currently does. In other words: a 401 error should always result in re-login via the Salesforce-hosted form; and a 403 error should almost always result in re-login, unless it's due to the fact that API is not enabled for the org and the error message so indicates. Are you seeing any other errors that shouldn't automatically indicate that re-login is called for? |
|
Agree with what you wrote. But I have been seeing periods from 10-30 minutes, typically over the weekends, where I consistently will get 403, with the same org that always works. Re-trying with credentials gives same error. Feels like it should be explained better to the user or handled by code.
Per
Per Jakobsen
(702) 416 7959
perbrondum@gmail.com
… On Mar 13, 2017, at 3:56 PM, Michael Epstein ***@***.***> wrote:
@pbrondum Salesforce will tell us, in the error message field returned in addition to the 403 status code, that the API is not enabled for the org. But other root causes for a 403 error should probably force a re-login, as Swiftly Salesforce currently does.
In other words: a 401 error should always result in re-login via the Salesforce-hosted form; and a 403 error should almost always result in re-login, unless it's due to the fact that API is not enabled for the org and the error message so indicates.
Are you seeing any other errors that shouldn't automatically indicate that re-login is called for?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@pbrondum in other words, the framework would keep track so that in the event of repeated failures, rather than trying yet again, an error message would get 'surfaced' to the user, i.e. a developer-configurable number of retries before giving up? In the situation you describe, it sounds like there's a more serious, server-side failure that's difficult to discern on the client side without keeping track of past results, and examining a series of failures within some given timeframe. That adds a lot complexity and requires logic on the client side to discover something that's not working as designed (by Salesforce). What error messages - in addition to the 403 status code - are you receiving? |
|
Michael -- The 403 is all I see. And only once or twice a week. But it's
painful enough that it should be addressed.
Error 403 is a bucket of failures, one being 'No API'. "Wrong
credentials', another one, which clearly is not my problem. Since this
happens over the weekends, and eventually resolves itself, I have a feeling
it's related to the OAuth service. Availability of server, of service,
anything in the path of checking credentials and returning the acceptance.
If I code around it to re-try the user will be looking at a spinning logo
for up to 30 minutes, or re-typing credentials to no avail for that period.
*Error 403:*
"A server that wishes to make public why the request has been forbidden can
describe that reason in the response payload (if any).
If authentication credentials were provided in the request, the server
considers them insufficient to grant access. The client SHOULD NOT
automatically repeat the request with the same credentials. The client MAY
repeat the request with new or different credentials. However, a request
might be forbidden for reasons unrelated to the credentials."
Thanks for any help in resolving this..
Per
…On Mon, Mar 13, 2017 at 7:07 PM, Michael Epstein ***@***.***> wrote:
@pbrondum <https://github.com/pbrondum> in other words, the framework
would keep track so that in the event of repeated failures, rather than
trying yet again, an error message would get 'surfaced' to the user, i.e. a
developer-configurable number of retries before giving up?
In the situation you describe, it sounds like there's a more serious,
server-side failure that's difficult to discern on the client side without
keeping track of past results, and examining a series of failures within
some given timeframe. That adds a lot complexity and requires logic on the
client side to discover something that's not working as designed (by
Salesforce).
What error messages - in addition to the 403 status code - are you
receiving?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#29 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA4tYowxQ_VenQYjowQZujCvWRNrdxZhks5rlfZxgaJpZM4MbUd5>
.
--
Rgds,
Per
per brondum jakobsen
perbrondum@gmail.com
+1 (702) 416 7959
|
|
@pbrondum
|
|
@pbrondum another reason for 403 response, unrelated to credentials and where it doesn't make sense to attempt to re-authenticate right away, is when the response payload contains 'REQUEST_LIMIT_EXCEEDED' -- exceeding the API request limit might also explain what you see for ~30 minutes on some weekends, especially if you're doing a lot of testing & dev within the preceding 24 hours. I'll update the title of this issue to include both cases: API not available (e.g. Prof. Edition), and API request limit exceeded. |
mike4aday
changed the title
|
That could explain it. Your suggestion would be awesome. Guess we could
query the ORG limits and keep track of usage but that seems excessive for
the client to do.
Thanks,
Per
…On Fri, Mar 17, 2017 at 12:03 PM, Michael Epstein ***@***.***> wrote:
@pbrondum <https://github.com/pbrondum> another reason for 403 response,
unrelated to credentials and where it doesn't make sense to attempt to
re-authenticate right away is when the error payload contains
'REQUEST_LIMIT_EXCEEDED' -- exceeding the API request limit might also
explain what you see for ~30 minutes on some weekends, especially if you're
doing most of your testing & dev within the preceding 24 hours.
I'll update the title of this issue to include both cases: API not
available (e.g. Prof. Edition), and API request limit exceeded.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#29 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA4tYj3qcULo5bgt5CSugD7OG2qkO0kBks5rmtkMgaJpZM4MbUd5>
.
--
Rgds,
Per
per brondum jakobsen
perbrondum@gmail.com
+1 (702) 416 7959
|
|
@pbrondum I'll include the changes in the next release. BTW Salesforce does return API limit info with every response, in the header (below), though Swiftly Salesforce doesn't currently do anything with it. If I found a useful way to surface the current state of API usage, would you code for it and take different action - or you'd just prefer to know after the limit was exceeded and tell the user to wait a while? Example of HTTP response header: |
|
Fixed in release version 3.5.1. |
For example, 403 error caused by Professional Edition without API should be handled differently (e.g. error exposed to end user) than other causes, which result in re-authentication and re-authorization via Salesforce-hosted form. See also Issue #27
The text was updated successfully, but these errors were encountered: