We have an API management instance in azure.We have also enabled the management API. There we have set a SAS token & that has been used in the application. Here, we have to change the SAS token in every 30 days. If the token is expired, that will result into an application outage. Is there any way to get notified via email or any other means about the token expiry (in advance). I did some research on this, but , unfortunately could not find anything useful.
I don't believe there is built-in support for this.
You could instead have a logic app that takes in a SAS Token as input and schedules emails based on the expiry of the token.
TIP Apart from an email, you could do more interesting workflows like sending actionable messages using office 365 outlook or https://learn.microsoft.com/en-us/connectors/teams/#post-an-adaptive-card-to-a-teams-channel-and-wait-for-a-response connectors and even create a work item in Azure Devops or create an issue on GitHub, depending on what you use.
Alternatively you could create Azure AD application with client id and client secret, give it permissions to do what you need to be done in APIM and use its credentials to do all the same operations via ARM.
Related
Is it possible to use any tokens from an Outlook add-in for use with authenticating EWS Managed API operations that create or update items?
Apparently the token returned from mailbox.getCallbackTokenAsync can only be used in read operations. I can indeed verify that is a problem because attempts to send emails or call UserConfiguration.Update result in an error:
The requested web method is unavailable to this caller or application.
I have been testing these methods from an ASP.NET Web API App Service in Azure, called from JavaScript in the Outlook add-in.
Apparently mailbox.getUserIdentityTokenAsync can be used to validate a user, but it is not clear if that can be used in conjunction with OAuthCredentials for ExchangeService.Credentials.
Are there any options here? I cannot ask the user for their username and password to authenticate with Exchange. I am certainly willing to use Graph or the Mail API, but AFAIK there are no ways to update user configuration items with those APIs.
You're looking for makeEwsRequestAsync(). Both CreateItem and UpdateItem operations are supported makeEwsRequestAsync.
You can find the full list of supported EWS operations in the documentation under EWS operations that add-ins support.
There is also support for calling into Microsoft Graph via the add-in but as you noted, Microsoft Graph supports a very limited number mailbox configuration options.
we have an production issue where the order is submitted twice. Currently we have an API for order and we are exposing this to client using API management and in these we have policies for URL mapping for customer facing to actual .
Now , our actual API got 2 request so we thought customer submitted twice but they have confirmed that they have not submitted twice , so either there is issue with API management which fired 2 request.
How can i Identify the request received by the API management ?
Is there any chance that API management will fire the request twice ?
Appreciate any pointers
The only way to fire request twice in APIM would be by the means of Retry policy or manually using SendRequest. Otherwise it should be a client calling your API two times. Each request in APIM get it's own unique id accessible in policies as context.RequestId, this is the main way to track and identify them. But these ids are produced inside APIM itself thus are useful only if you're tracking a call from APIM and into backend.
Your best option now is to try to identify requests by client ip, method, uri, and time frame. APIM allows you to grab logs for certain periods of time (better if kept short) in JSON or CSV with data I mentioned above. To do that look into byRequest report (https://learn.microsoft.com/en-us/rest/api/apimanagement/reports#ReportByRequest), grab JSON/CSV and try to identify calls of interest,
For future you could look into onboarding your service to azure monitor (https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-use-azure-monitor) or log analytics those provide easier way to traverse logs.
We used to have an application connector implementing the Document List Service v3 to upload documents to users account. Now that the service will be discontinued starting as of next Monday and we need to migrate to the Drive API/SDK we have the problem to migrate our current login schema .. we are unable to use the OAuth 2 protocol and we need to authenticate users with their username/password credentials.
DocumentsService myService = new DocumentsService("xxx");
myService.setUserCredentials(username, password);
The reason is that our application scans and processes documents asynchronously from MFD devices (printers) and all processing/storage job is done in a different moment on processing servers, thus the limitation that the processing service cannot ask any consens to the user.
We do the same for other online cloud storage application (e.g. Dropbox) where they allow special 'OAuth 1' schema on request for such 'enterprise' situations.
How can we do this with the new Drive API/SDK? I couldn't find anything about that in the documentation rather than the service account, also looks like not suitable.
What you need to do is request authentication from you user once. The server gives you back a refresh token. Your automated application can then use this refresh token to get a new access token. You only need to ask the user one time for authentication. Then everything can run automated.
A service account wont really work in this instance because its meant for use with an account that you the developer own not a users account
I'm creating a web app for my company that will keep a number of files in sync with the files on Box. This will be done by using a cron job running every hour.
I have the application working by setting the developer token in my account, this was done for testing whilst I was building the application.
Now this is working I want to get the authentication working so I can just leaving this running. So I'm trying to work out if there is a way I can have an API key for our enterprise account or if I will have to implement OAuth and connect one user to the application, which seems to be a bit overkill?
You should probably use one of the SDKs, which take care of refreshing the tokens for you.
Essentially what you'll need is a keystore to store the tokens. You could store the Refresh-token only. When your cron wakes up, use the refresh token to get a new access-token and refresh-token. Store the new refresh token in your keystore. Then make your API calls using the Access-token, and then go back to sleep.
I'm in the middle of developing an application that integrates Box with an identity management environment for the purposes of SSO and user lifecycle management. Basically, our users use SAML to sign into their Box accounts, and then the status of their Box accounts is managed based on the status of their corporate accounts - if we terminate a user, the user's Box account needs to get disabled. This is one of many use cases that were in progress before the OAuth2 change.
Prior to the OAuth2 change, I was able to authenticate my enterprise admin account with the api_key and auth_token. This worked very well.
Now, with OAuth2, I'm not sure how to proceed. There is no UI for this at all, and I have no place to handle a redirect for the authorization token. Moreover, this is a nightly process that runs using the enterprise admin account, so I would have to get a new refresh token and bearer token every time this runs.
This doesn't make a lot of sense for my use case. Is there an alternative?
I am busy writing the same code with the same frustration as you have. However the refresh token does live for 14 days and what I plan to do is store the returned values encrypted in the registry. Each run my first action is to refresh the bearer key.
There however is no current timeline on the phasing out of the V1 Auth method and since some of the Enterprise stuff is yet to be ported to API V2 I suspect that if enough Enterprises push the BOX API team for a solution on this I am sure they will listen.
If I am honest I prefer the OAuth2 solution as it stops the key to your whole Enterprise data been sent in clear text across the internet as a URL param in API V1 and if someone did manage to break the SSL then only get a access token that is worth 60 mins max.
Not sure what language your writing the routines in but I am working with the API V2 SDK written by John Hoerr on GitHub and apart from a few little issues that he has fixed straight away from a .Net perspective it makes hitting the API a much more pleasant experience with all the de\serialisation handled by the SDK.