When sending a notifications to a notificationhub I receive the following exception:
Microsoft.ServiceBus.Messaging.QuotaExceededException: The remote
server returned an error <403> Forbidden. The maximum number of
Notification operations has been reached or exceeeded. Actual:33360,
Max allowed: 33000..TrackingID55ccd1f7a791-4047-96fd-0d0be2278ff7_g7
Any ideas on how to fix this problem?
What you should keep in mind is that it appears that all operations (not only sending notifications) you do with the NotificationHubClient seems to add to your daily Operations Quota.
I have made the mistake of doing unnecessary registration updates whenever the client logs on to my API.
Device registrations are valid for 90 days, so I'll not have to make any updates unless the registration has/about to expire. (I do save the expire date, which you'll get from the RegistrationDescripton.ExpirationTime, in my user table in my server app for knowing when to do a registration update)
Related
In my app, I allow my users to authenticate with their existing google, microsoft, etc accounts via OAuth2.
Everything runs smoothly. Upon getting callback to local redirect url, I successfully request and receive bearer token from endpoint. With access token in hand, I then request UserInfo from user info endpoint. I then compare email address in UserInfo JSON object with the email address registered in user record and if they match, I consider user signed in.
Now, my question is regarding bearer token and session timeouts.
Google bearer token looks like it authorizes for 60 minutes; while my server session lasts 30 minutes (I haven't changed the default).
Since user already got successfully authenticated, the session id will remain active and alive while there's activity within every 30 minutes. However the bearer token expiration will have expired after an hour.
I would normally assume that I need to refresh the access token before it expires so long as there's activity within the established server session. However, google does not appear to have a refresh token endpoint.
But even if it did, would it be desirable to do this?
Or since the fact that I have an active session id from an authenticated user is enough to allow access to protected resources while only the session id is 'alive'?
I'm assuming it is, since some websites allow customers to maintain their sessions for days at a time, at which time, bearer token would have expired long before.
And lastly, how long would you recommend I keep my users (customers, really) with an open session? My website is on online store.
Thanks to all!
Your session can be completely detached from Google's session. You should only be concerned whether your session is still active. The validity of the access token from Google is not relevant here. Remember that the expiration time of an access token has, in fact, nothing to do with a user's session at all. E.g. you log in a user using Google. The user authenticates at Google and you get an access token, which is valid for 60 minutes. The user then logs out at Google. Your access token will still be valid until that 60 minutes pass, even though the user logged out from Google, and her session is no longer valid there.
As for the length of the session, this is really up to you. If you know your customers are likely to come back often, and you want to make it easier for them you can even keep a session indefinitely. In such a scenario you should think about security and privacy - if the user leaves their account logged in on a shared computer, how much could it hurt them if someone else manages to use their session after a week or so. If you know your customers are likely to come back every few weeks or months to your store, then it really doesn't matter if you keep the session open for a day or five. Most of them will have to log in again anyway.
So to answer the question of the length of the session you should study the behavior of your users and take into account security and privacy issues.
We have desktop and mobile app (2 different client id) integrated with bim360 api. We have a problem with 429 error responses. Documentation: https://forge.autodesk.com/en/docs/data/v2/developers_guide/rate-limiting/ doesn't give us a lot of details.
How does it work? How can we avoid it?
What will happen if 1000 different users from apps with the same client_id at once try to get issues list? Will it be distinguish as Ddos? Are hubId, projectId, user account, ip address considered in rate-limiting algorithm?
As I know, each API has a well-configured rate-limit per minute per client id. After reaching the limit, you will see a retry-After parameter appears in the response header of each of your API call. It stands for the retry time when you can call the API again, and the unit of this value is in second. You can schedule a retry task along this retry time in your code.
Note. The value of the retry-After will reset if you make another call before reaching the Retry-After duration.
Hope it help, Cheers!
I am using ExactOnline API to fetch the transactions, my API is working fine, but suddenly the Error 403: Forbidden - The division is blocked error occurs and API return the empty result.
Please help.
Thanks.
An HTTP 403 with reason "The division is blocked" typically means the administration is temporarily blocked by a process that needs exclusive access to the administration. Examples are:
One of the company's users is creating or restoring a backup of the administration.
Exact is moving the administration to a different database. (After office hours; users are notified in advance through Exact Online's workflow system.)
API clients should be able to handle this situation. The typical solution is to try again at a later time.
You can find a full list of response codes here:
https://support.exactonline.com/community/s/knowledge-base#All-All-DNO-Content-respcodeserrorhandling
I'm synchronizing Office 365 mail folders via the Office 365 REST API by doing a GET on me/MailFolders/{folder_id}/messages. For two different accounts, I've recently been getting 500 responses to these GETs with the error code ErrorMessagePerFolderCountReceiveQuotaExceeded and error message "The number of received messages has exeeded the quota for the folder." (Typo theirs, not mine.)
I can't find any documentation on this error. What does it mean? What should I do to fix this situation?
I couldn't seem to find any documentation for it either.
From the error message, it seems it might be related to the "Maximum number of messages per mailbox folder" limit on Exchange Online. Do you know if the folder contains 1M+ messages?
https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx#MailboxFolderLimits
I guess my other idea would be that you're getting too many messages in too short of a time period. Suggestion would be to use the endpoint GET https://outlook.office365.com/api/v2.0/me/MailFolders('{folder_id}')/messages with $deltaToken and $skipToken to skip previously synced messages.
https://msdn.microsoft.com/en-us/office/office365/api/mail-rest-operations#synchronize-messages
When you do a sync to an Exchange folder via the Outlook REST API, you pass it a sync token. In response, the API returns a new sync token and a set of changes. And the client is expected to send the new token back with their next sync request.
With most systems that support sync, using a stale sync token (i.e. one that has been sent to the server once) in a subsequent request will generally just succeed with no problems. And Exchange appears to work like that... for the first 999,999 times you do it. On the 1,000,000th time (and each time thereafter), you get ErrorMessagePerFolderCountReceiveQuotaExceeded. This is (I think) because Exchange keeps track of each token that it's given out and updates the token in its store each time it's used for sync. If a client uses a stale token, Exchange views it as a new client and adds that stale token as a new entry in its list of active tokens. That active token list can have at most 1,000,000 entries. ErrorMessagePerFolderCountReceiveQuotaExceeded is the cryptic error indicating that Exchange's active token list has overflowed.
I am trying to implement OAuth2 for a REST API which will support mobile, desktop and web apps.
I have read Chapter 6. Refreshing an Access Token of Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012
According to RFC, access tokens and refresh tokens are saved into DB and I am doing so using MySQL.
My question is at which point/activity of OAuth2 should I remove all expired access tokens and refresh tokens.
Should I run cron job for that?
I have to read about it though seems difficult to me
Verify that the MySQL Event Scheduler is enabled on the server. If not, enable it.
Assuming the table is called "token" and it has a column called "expires_at" and that column has an index on it, and then create a scheduled event with a query like this:
CREATE EVENT purge_expired_tokens
ON SCHEDULE EVERY 15 MINUTE
DO DELETE FROM token WHERE expires_at < NOW();
Every 15 minutes from the time you originally defined the event, the server will run that query in the background and purge any expired sessions.
Yes, you should periodically run a program that deletes expired access tokens, refresh tokens and authorization codes.