How does one edit how fields appear after data is sent to okta in a testing environment? See Screenshot
Okta Test Environment
as you can see we can only edit the data on the okta side and change what is being sent but not what is being shown.
Tried to edit in the test environment, but confused on limited instruction as per Okta.
Asking for a Friend.
Thanks!
Related
I'm attempting to use Outh authentication for my PHP request to Salesforce but I can't get my ClientID and SecretID for my app.
I normally have an option to View these values but for some reason I'm unable to view them with an administrator login.
I created a new App and was able to get the credentials successfully, so I know it's not the account permissions preventing me from accessing this information.
Does anyone with experience of Salesforce have any experience with an inability to get these details?
Thanks!
Is it a normal app created in this org or managed connected app, coming from installed package? You can't see secrets of managed app.
For normal app they're hidden behind a button. For me clicking it takes me to email challenge (provide OTC or one-time code we've sent to your mailbox). Completing that I can access the page with key and secret I can copy-paste.
Your user might be misconfigured. Try to fish around with browser's source inspector, maybe the button's there but doesn't render?
<input id="appsetup:setupForm:details:oauthSettingsSection:manageConsumerKeySecretSection:manageConsumer" type="submit" name="appsetup:setupForm:details:oauthSettingsSection:manageConsumerKeySecretSection:manageConsumer" value="Manage Consumer Details" class="btn gsbutton">
Is your email valid in this org (maybe it's a fresh sandbox with ".invalid")? Do you use Multi Factor Authentication? Do you think you have "high assurance session" configured when accessing certain areas of setup? Can be in Setup -> Session Settings or in your Profile
thank you for writing back to me regarding the issue.
The issue I encountered was trying to get the API credentials for an existing app but I was able to create a new App which is posting the Leads successfully into the system.
So the answer to my problem was that the original app was misconfigured when it was created and I was able to create a new App to resolve the problem.
I am trying to authenticate with Okta in my iOS app, Create a app is Okta dashboard and added client id and redirect url's. After setting up and installing app in simulator. app is throwing the below error:
Please let me know if i missed any settings.
Created a native app from dashboard.
It looks like the client ID you're sending in the request is not what you think it is. You should be able to copy the URL from your browser, paste it in something like Notes, and examine the client ID. Make sure it matches what you have in your Okta org and that it doesn't contain any unexpected characters in it.
That's a common problem being faced by every newbie.
Here are some steps which will guide you to make your Okta authentication without error.
Create an application in Okta Page.
At text field & you may put your domain id. ex dev-xxxx.okta.com:/callback
Provide the same detail in your okta.plist in iOS Application.
You may refer to the Okta 'GitHub Repositories' for working samples.
Thanks.
I am trying to disable my logic app via a Http post from within the workflow, but I can't seem to get the authorization to work with my AD.
It says I need the Authorization Bearer token header, but when I fill the information in the fields marked with the red star it always fails.
Either I input the wrong information or I am doing something else wrong.
Where do I get all the information for the fields for the OAuth to work?
Also isn't some of these for using against a web application like an API?
In that case how do I do this only in relation to the resource explorer API?
UPDATE
So i have tried to put it as a web application in my AD and that doesn't work either, is there ANY documentation about this anywhere??
OK, so i found a workaround or maybe this is even the right way to do it.
Now using a HTTP Post Connector in Logic apps is probably the right way to do it when you have for example a API registered as an application in you AD that has the right permissions. what i did was:
First: Using/Created the Azure Resource Management Connector i didn't know excised, called "Invoke Recource Operation".
Second: After it propted you to login (with for example a service account), this layout is show to fill in the same inputs as in the request POST URL in the above connector.
Shown below:
This worked and disabled the LA perfectly.
I'm working with the PayPal API and am trying to create an account as shown here.
The request is made to https://svcs.sandbox.paypal.com/AdaptiveAccounts/CreateAccount.
I'm able to send a valid request and get a response indicating success back but the redirect URL that's also returned as part of the response payload (which according to their docs is supposed to take the user to a PayPal sign up/registration page) is directing them to the following:
I've been unable to find anything on Stackoverflow or Google regarding this. Has anyone encountered this before? I'm assuming that even though it's a sandbox environment it should allow me to simulate the workflow somehow. I've tried with both the default sandbox credentials as well as for my own environment.
Looks like the issue was due to the IP address header in the request. The default configuration is:
-H "X-PAYPAL-DEVICE-IPADDRESS: 192.0.2.0"
While testing on localhost, I changed it to:
-H "X-PAYPAL-DEVICE-IPADDRESS: 127.0.0.1"
Also had to ensure that the email address didn't already have an account registered to it - in which case it would lead to a login page instead of the registration page (which is a little poorly designed in my opinion since you can't really test without making new accounts each time).
I'm working on a Box integration and have run into an interesting scenario:
Box user right-clicks in Box and selects an action
The user is sent in an iframe to the client_url.
Since in box we have to keep track of each users' access and refresh tokens, on this pass we discover in our application logic that the user lacks valid tokens.
As per the docs we send the user to:
GET https://app.box.com/api/oauth2/authorize?response_type=code&client_id=MY_CLIENT_ID&state=security_token%3DKnhMJatFipTAnM0nHlZA
and from there Box sends the user to the configured redirect_uri. My question is after authentication, how do we get back to the confiured client_callback url that we configured for our Box application? I don't see a way of getting back to our original url since we had to inject a view for the Box authentication and are then routed to the oauth callback url.
Thanks!
https://developers.box.com/oauth/
From the Box Support team:
Paul Paulauskas (Box Customer Success)
May 27, 4:26 PM
Hi,
The Box web app integration was never designed around having a full authentication flow. When a web app integration is called, it can deliver an auth_code (it's one of the parameters that you can choose), which can be used to create an access token and a refresh token. This is discussed under the "Popup notification" section of:
https://developers.box.com/box-web-application-integrations/
Let me know if this helps!
Thanks,
Paul
Box Platform Support Engineer
In short, the Box app integration configuration looks like this now:
Note the auth_token attribute is the same as the code attribute returned by the authentication workflow described in https://developers.box.com/oauth/