I am using Azure AD graph REST API to get all users on the Azure Active Directory. I am also using paging while getting those user.
At the end of each page, api returns token for the next page. Which is used to get next page of users.
It looks like this - "odata.nextLink": "directoryObjects/$/Microsoft.DirectoryServices.User?$skiptoken=X'226370740200010000003E3ACDE316230633836636636373430323861666235626436306537366132306139407361696C706F69AEFDE746465762E6F4F4F4F418F736F66742E636F6D29557365725F383461663866351238412782482433372D626439312D336239633930373536383464B900CCCC00001111000000'"
}
For some reason if there is delay in using this next page token, it expires. API throws error 'Bad Request The specified page token value has expired and can no longer be included in your request.'
So how to regenerate valid page token for next page without starting again from the beginning ?
What is the default validity for the page token ? I guess it is 1 hour. Is it possible to increase this time ?
Looking around on existing graph documentation, there is no mention of any explicit manner to extend this token.
Considering there does not seem to be a way to extend it, you should make your app code advance as much pages as it did (caching it somewhere), to continue from there.
You should also consider restarting from the beginning, as one hour can be long enough to have your user list potentially been modified.
Related
I've built an API-based integration with DocuSign (using their PHP SDK), and am now at the point of deploying to the production server. I have reconfigured everything with the production integration key, public/private key pair, user and account IDs, endpoint URL, etc. replacing the demo ones. The OAuth portion of the conversation is working fine, and I get a valid token back. When I then try to send an envelope, I hit a USER_LACKS_MEMBERSHIP error, and cannot figure out why. As far as I can see, everything about the API user is the same between the demo and production systems.
I've authorized the application and made sure that it's in the list of "Applications with Access to DocuSign".
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Most of the documentation that I can find on this simply repeats the generic error text: "The UserID does not have a valid membership in this Account." If I go to the account admin and look at the list of users, the one I'm expecting is right there, with DS Admin permission; not sure what else might be done to give them "membership". One mentioned not using SendOnBehalfOf, but I'm not, so I can't really remove that.
All the code is identical, just configuration that's changed. Not sure where else to look. Anybody have any suggestions for what to try?
FURTHER INFORMATION
I've tried the getUserInfo call in the SDK, passing the same access token I use for the other call. It returns successfully, showing that it is for the user I'm expecting, in the one group we have, on the production server. And yet, when I enable logging again, as this same user, there is still zero record in the resulting logs of any of this API activity.
Attempts to do things like list templates with the SDK fail with the same USER_LACKS_MEMBERSHIP error.
Using the Diagnostics API (again, through the SDK) to check logging status shows that it is NOT enabled (despite my enabling it in the UI), but can be enabled with a separate call. Subsequently attempting to use listRequestLogs in the SDK generates a 404 error, though the URL matches what's listed in the API documentation (/v2/diagnostics/request_logs). Not sure whether these findings confirm that I'm somehow logging onto the API and the UI with different users (even though the user name and internal ID match), or that there's some problem with the logging facility in DocuSign.
The problem turns out to be the URL I was using for API calls. I switched from demo.docusign.net in testing to www.docusign.net in live, but being in Canada we need to use ca.docusign.net. For those who find this later, you can get the correct base path to use from the oauth/userinfo endpoint, or the getUserInfo() call through the SDK (PHP SDK, at least; don't know what the analogous call would be in others).
There are 3 things to consider:
API calls are made to an endpoint (URL) that contains the account # (either GUID or short form) in the url. Take a note of that number in the url.
Auth Token is a token for a specific user in a specific account.
UserId for the specific call. That is a specific user in the account.
If the user is not in the account, or there's a mismatch between #1 and #2 - you'll get this error. You must work with a single account and have it in all places as well as the user must be a member of this account.
Re:
I have enabled logging, but the only things that are showing up in there appear to be from my own navigation in the site, nothing related to the API calls at all.
Since the request logging is not showing your API activity, the problem is that the person you've logged in as on the web tool is not the same as the person (user id) that you've logged in as on your application.
Solution for OAuth Authorization Code authentication: double check that when your app is logging into DocuSign, you're using the account.docusign.com authentication server, not the account-d.docusign.com auth server. (Look at the URL in your browser during the login sequence.)
Solution for OAuth JWT authentication: re-check that the impersonated user id is from the production system and you're using the right authentication server
I am setting up a static website on Azure Storage that will basically be a single page where a user must fill in a value and then press a button. I generated a SAS that expires after 24 hours, but the other part I am struggling with is to limit access to the generated URL to a single-use only.
I've tried reading through the Azure docs on Microsoft's site but I couldn't find a way to do it
Basically I expect a user to click on the link and it should take them to the html page. But if they try and click on it a second time, it should throw an error saying that they cannot access the page or just give like a 403 response
It is not possible to define a SAS URL with number of times it can be used. As long as SAS token associated with the URL is valid, a user will be able to use that URL.
For this, you would need to use some kind of middleware. Essentially instead of taking user directly to SAS URL link, you take them to a separate link with a unique token. When the user lands there, you check if the token has already been used (by looking up in a database) and then take appropriate action i.e. either allow the user to the final destination or deny access.
We have a client who has a simple Instagram feature on the site to pull photos by a certain tag. They just noticed it isn't working. Getting an error - invalid access token. I guess since the 1st because of the updates. We didn't used to need an access token since we're not doing anything with users - just tags.
Now it looks like we need one and the documentation makes zero sense on how to obtain one. And it seems like they're not accepting most apps. The app is in sandbox mode too. So I'm assuming it's because it got switched to that? Got no notification of this happening.
The first step in documentation to get an access token is "Direct the user to our authorization url." What does that even mean? There's not a link provided or anything. It also says "Company Name, Contact Email and Privacy Policy URL are required to start a submission." Our app doesn't have a privacy policy... it's just a simple tag feed. I don't understand why everything is so complex to have a simple tag feed.
Is there a wait time to get the app approved..if it gets approved... Do I have to have it approved before getting an access token? This isn't outlined anywhere.
You got it right. As of June 2016 any Instagram API calls require an access token.
Getting an access token is described in the documentation. App approval is not required.
There are two ways to get one: server-side or client-side. The second option (called implicit authentication) can only be used when implicit OAuth is enabled in the client settings (Manage Clients > Edit Client > Security > Disable implicit OAuth). It is disabled by default.
In either case you need to redirect the user to the authorization URL to obtain an access token.
The URL for explicit mode (server side) is:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code
The URL for implicit mode (client side) is:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=token
After this you will be redirected to the REDIRECT-URI, which will be passed an argument. For explicit mode this will be a query string with a code, while for implicit mode you will get the access token directly as a hash:
http://your-redirect-uri?code=CODE
http://your-redirect-uri#access_token=ACCESS-TOKEN
For implicit mode you can then get the access token from the window.location.hash in Javascript.
For explicit mode, however, you need to further process the code to obtain the access token. You can read how this can be done in the API Documentation. I'm not going to take this any further here.
The problem is that every user who wants to see your feed needs to login to Instagram (and have an account) in order to view it. In your case this might not be desired. However, there are a few options to get around this (rather annoying) problem:
You can reuse your own (already obtained) access token(s) to display the Instagram feed for every user. You will need to be aware of rate limits for each token. For sandboxed apps this is 500 API calls / hour, while live mode allows 5000 API calls / hour. [source] You could store tokens in a table and use them in a round-robin manner, to allow more API calls. This involves manually obtaining a bunch of tokens which your application can use (the more the better). This might not be the ideal solution considering Instagram doesn't warrant access tokens to have an unlimited lifetime.
You can retreive JSON data without authentication by appending /media/ to a user page URL, as described in this post. No tokens or client IDs are required for this to work. However, this only works for users, not for tags. Besides, Instagram doesn't document this feature so it is not garanteed to work in the future.
You can use an aggregator like Juicer or Dialogfeed instead which will handle access tokens for you. This is usually not free of charge.
I'm also in the process of making an Instagram feed for my website, and this is what I concluded from my research. Please bare with any errors I made.
Edit: Here are some more limitations for sandbox apps.
In sandbox mode you can only access data from sandbox users (thus users who received a sandbox invite). This means that:
Media retreived by user, e.g. /users/{user-id}/media/recent, will return an empty response if the user is not any of the sandbox users.
Media retreived by tag, e.g. /tags/{tag-name}/media/recent, will only contain tagged media belonging to sandbox users.
Thus, for a tag feed to work, it needs to be live (reviewed and approved). If you don't want to do this, the only alternative is to use an aggregator as I mentioned above.
I am trying to get data from Netsuite using RESTlet. For that, i am using the following details in PHP:
Consumer Key
Consumer Secret
Script Id
Deploy Id
Access Token Id
Access Token Secret
At first time of using these details, i got that error is Invalid login attempt.
I found why it is coming , because of the following any one or all of the wrong details.
Consumer Key
Consumer Secret
Access Token Id
Access Token Secret
After giving correct details it works fine and i stored all these details in DB. I didn't change anything. But after few days i am getting the same error.
I want to know whether the access token will expire after some days or why the error is coming.
I recently had similar issue, everything worked on my machine, but fail with same exception on the test server. Carefully debugged and saw that timestamps for generating request access token are with 12 min difference.
After synching times everything went fine. So even token definitions in NetSuite doesn't expires, timestamps for generating request tokens must be in 'some' time-window with time in the NetSuite environment.
Too bad that SuiteAnswers (https://netsuite.custhelp.com/app/answers/detail/a_id/44241/kw/44241) doesn't mention anything about time.
If you are trying to access a RESTlet through Token Based Authentication (TBA) and are receiving the INVALID_LOGIN_ATTEMPT error and the login audit detail is permission_denied, then the following may work.
Ensure that the role:
Isn't an administrator type role
Doesn't have the Web Services Only Role checked
Also double check that your related integration has the TOKEN-BASED AUTHENTICATION checked.
Note: to check your audit trail detail, go to Setup > Users/Roles > View Login Audit Trail, check USE ADVANCED SEARCH, and be sure to add Detail as a result column.
In my case I was getting the account id from the URL which is lowercase, while it should be upper case.
I was testing on a sandbox and sb1 should be xxxxxx-SB1 on the URL and Realm should be xxxx_SB1
Finally I found the answer for 403 error in my case, I changed the time offset with my standard CST time zone, and repost, it worked.
If you found this 403 error and have been trying every ways, check the time on your machine
If you are using user credentials for RESTlet Authentication ensure that the role in use doesn't have the web services only Role checked.
It has to ensure the token (Token ID) matches the proper Application on the Netsuite side.
Setup -> Integration -> Manage Integrations
I have a personal website on which i want to display my latest facebook comment. Everything works fine, but I'm not sure how the access token expiration works. I have a two months access token, so does it mean that every two months I have to get a new access token and replace the one in my code. If so, it's really not convenient at all... especially since all this is to authorize MYSELF to get my OWN comments.
Is there a way to automatically renew the access token or to get a token that doesn't expire or any other way around this two months expiration thing?
According to Facebook documentation you can ping this URL, which will either return the same access token (if there is time left) or a new one (if there is not time left). This will return a string with a token and an expire time.
https://graph.facebook.com/oauth/access_token?client_id=APPID&client_secret=APPSECRET&grant_type=fb_exchange_token&fb_exchange_token=TOKEN