I am trying to implement SCIM Integration with OneLogin. Create, Delete works fine, but on updating a user, my server sends a 200 OK response, still OneLogin server provides me an error without any further description.
Its an "INTERNAL PROVISIONING ERROR"
How to check whats wrong within the scim application with only this detail?
Reach out to developer support at OneLogin (scim-support#onelogin.com). At the end of the day, you're probably sending badly formatted JSON which causes the parser on their end to barf.
One item I've noticed recently is that folks are including // comments in their JSON and that's No Bueno (at least for OneLogin's parsers)
Related
I use the version 9.0 of the Grapph API. The leads retrieval was wroking ok, but the last 3 weeks I am not able to retrieve lead form information, using the endpoint :
https://graph.facebook.com/v9.0/${leadId}/?access_token=${process.env.FACEBOOK_PAGE_ACCESS_TOKEN}
The page access token as well as the facebook app has all the permissions like leads_retrieval, pages_manage_ads, pages_manage_metadata, pages_read_engagement, business_management, public_profile, pages_show_list.
When I create a lead form id from the page that is connected to the app, and then use the testing tool (https://developers.facebook.com/tools/lead-ads-testing) to check if the webhook works, everything works ok !!
The facebook and the connected page that are connected and were used for testing purposes, do belong in different businesses.
The problem is that when someone submits a lead from paid campaigs, then the following error message shows:
An invalid response was received from the Facebook API: {"error":{"message":"Unsupported get request. Object with ID '1223289864932223' does not exist, cannot be loaded due to missing permissions, or does not support this operation. Please read the Graph API documentation at https://developers.facebook.com/docs/graph-api","type":"GraphMethodException","code":100,"error_subcode":33,"fbtrace_id":"AIQ5Q-yJo249IZwdn10dfhi"}}
Is there an error in the set up of the whole system? Something that needs to be changed? Why suddenly did it stop working ?
My website has been using DocuSign Connect API (SOAP) for years without issue. Part of my website utilizes the brand creation functionality of the DS API (CreateAccountBrands). This has worked flawlessly until very recently.
I now notice in the DocuSign Demo environment that the CreateAccountBrands calls return an InternalServerError with the message "Brands could not be created" but no other information is present in the trace log file. All other DocuSign API calls still seem to be working fine.
Nothing with my payload has changed at all. Has something recently changed with the payload requirements of the CreateAccountBrands call?
I thought it could be that you reached the limits for brands but it seems to be 1900+
You can check Docusign's release notes to see if there are any relevant changes here: https://support.docusign.com/s/releasenotes?language=en_US&page=1
If you don't find anything then you can reach out to DocuSign's support by opening a ticket here: https://support.docusign.com/
I was using the following api to get the latest 3 posts from public accounts to show on the website:
https://api.instagram.com/v1/users/{user-id}/media/recent/?client_id={client-id}&count=3
I had created an app to get the client-id.
However from today, this API has started throwing the following exception:
{
meta: {
error_type: "OAuthAccessTokenException",
code: 400,
error_message: "The access_token provided is invalid."
}
}
Could you please let me know as how to resolve this?
Based on the date, you probably have an older app that got hit by the API migration today, like mine. In short, Instagram decided to make developing for their platform WAY more annoying by requiring all API requests to be authenticated per user, even for data that users shares publicly. So you (like me) will likely be redesigning you app entirely.
To tell, log in to instagram.com/developer and click manage clients; then hit edit next to the set of keys your're trying to use. Up near the top, it will have a section called 'Client Status' -- if yours reads 'Sandbox Mode', fun times ahead! Hopefully you interact with less than 10 users and can stay in sandbox mode, otherwise you'll have to write an essay, film a video, and basically plead to get your permissions back (probably in a few months, when some Instagram intern finally digs his way down to you in the pile of applications). If it reads something eles, you've got another problem altogether and should thank your lucky stars.
In the meantime, I guess I'll get back to sending out dozens of emails to the maintainers of our many, many affiliated Instagram accounts to explain the issue and try to get permissions, so provided we get approved by then, all our social media displays aren't broken during a huge event Saturday. Another option might be to use the OAuth-less json response available here, but that might break terms of service.
I have a solution to this. If you are using the same code I am, which appears likely. I was pulling the last two images using this.
https://api.instagram.com/v1/users/{user-id}/media/recent/?client_id={client-id}&count=3
What I did to get this working is the following.
Login to your Instragram account you are using as the application.
Go to the developer (API) area. https://www.instagram.com/developer/clients/manage/
Manage clients. Make sure your website URL is the same as your valid redirect URL.
Add new Sandbox User. Put in the account of the IG photos you want to reach.
Hit this URL: https://api.instagram.com/oauth/authorize/?client_id=CLIENTID&redirect_uri=REDIRECT_URI&response_type=token where the client ID is the same one you used in your previous app above.
You should get back and access token URL. Copy your access token.
Login as your account that you want the IG photos of. The account you added as a sandbox user and go to developer and approve the Sandbox Invites.
Change your original URL above from https://api.instagram.com/v1/users/{user-id}/media/recent/?client_id={client-id}&count=3 to https://api.instagram.com/v1/users/self/media/recent/?access_token=ACCESS_TOKEN with your access token.
This is the IG API Media endpoint documentation: https://www.instagram.com/developer/endpoints/users/
After that, it all worked for me and while you are in the sandbox, you should be able to pull the last 3 photos or at this point, figure out how to read the JSON to do so.
Has your app been approved after the June 1st Instagram platform changes?
http://developers.instagram.com/post/145262544121/instagram-platform-update-effective-june-1-2016
If you want to retrieve the user media file then try this, It's working for me
https://graph.instagram.com/me/media?fields=id,caption,media_url,media_type&access_token=ACCESS_TOKEN
For some reason the token is no more valid. Request it again.
Possible reasons why a token is no more valid:
changed password
verified the account
logged-in from a different country
I'm currently trying to automate the process of creating a docusign document and sending it by putting it into an apex trigger. I have managed to get the docusign api (via WSDL) into my org, and now I'm trying to add the code into the trigger to send out the document. Without pasting the entire code here, I've been following this tutorial and have gotten all of the required code into my trigger. Unfortunatly, when I run it, I get this error:
11:40:49.965 (12965647595)|FATAL_ERROR|System.VisualforceException: Getting content from within triggers is currently not supported.
Trigger.OpportunityTrigger: line 109, column 1
Does this mean that it's not possible to send a document in a trigger? The tutorial sends it through a controller, is that the only currently supported method?
Thank you for any help you can give me!
EDIT:
So I've gotten past that error (using a different tutorial), and am now getting this error.
System.CalloutException: Web service callout failed: WebService returned a SOAP Fault: This User lacks sufficient permissions. User does not have the permision to the CreateEnvelopeFromTemplates method faultcode=soap:Client faultactor=https://demo.docusign.net/api/3.0/dsapi.asmx
This appears to be a problem with the Docusign user I am using for sending this document. I am currently using CreateEnvelopeFromTemplates to try and send a templated document out to up to 5 recipients.
I ended up phoning into Docusign Support, and asking them about the issue. Turns out that the last error was caused by me trying to authenticate and sign into docusign with my userID not the AccountID (switched those around and the permission error went away).
Another error showed up related to not having roles setup properly in my template (fixed that by setting up the role), and now everything is working fine. I'm answering my own question to leave it as a reference to future searchers.
Create a call out from trigger
Then get the request from a rest method
Then continue to get the pagereference conten
You can find an example here
We use OWIN middleware to log people in to our cloud application using OpenId Connect.
The issue is, we also want to access their Office 365 data through the new APIs.
Using OWIN to log in doesn't return us to our website with a CODE, and so using ADAL we send them right back to consent a second time and then get our tokens, etc...
Can we do this in one swoop?
Here is what Fiddler says OWIN uses to authenticate:
https://login.windows.net/common/oauth2/
authorize?
client_id=ourguid
&nonce=random characters
&response_mode=form_post
&response_type=code+id_token
&scope=openid+profile
&state=OpenIdConnect.AuthenticationProperties*more random characters*
&redirect_uri=http%3a%2f%2flocalhost%3a8683
&post_logout_redirect_uri=http%3a%2f%2flocalhost%3a8683
I see code+id_token in the Query String, but when it sends me back there is nothing in the URL at all.
You can do everything in a single leg in OpenId Connect via our OWIN components, there is a specific notification that is triggered when you get a code back and that you can handle to redeem that code.
See the sample at https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet and specifically Startup.auth.cs for a demonstration of how it works.
Note: the RC we just released will make the code much simpler. I am still working on updating the sample to thate ffect, you can take a look at the RCUpdate branch to see the work in progress. However what is in the master branch is functional hence that should unblock you.
HTH!
Cheers,
V.