I created a bot in my own sandbox using Circuit JS SDK.
self.client = new Circuit.Client({
client_id: config.client_id,
client_secret: config.client_secret,
domain: config.domain,
autoRenewToken: true
});
Here domain value was "circuitsandbox.net"
Now I want to connect it with bot's account in real Circuit Enterprise domain. What value should I use for domain now? How can I find this if I'm not an administrator of domain?
The domain will be the system your tenant is located at. You can see this in the URL you use for your circuit client. Unless its a special onprem deployment, the production domain will be either eu.yourcircuit.com or na.yourcircuit.com.
If you don't have a production tenant yet, you can request a free tenant. See step 3 at https://circuit.github.io/
Related
We have 2 domain in salesforce:
1-) https://gablesinsurancerecovery.my.salesforce.com
2-) https://gableinsurancerecovery.force.com
and we have 2 user:
developer#cloudspade.com
communitytest#cloudspade.com
developer#cloudspade.com mail work with success on 1. domain but not work on 2. domain.
Likewise, communitytest#cloudspade.com mail work with success on 2. domain but not work on 1.domain.
Its not a problem. Problem is:
2.domain is important to us. Because we have a react-native project by forcereact and we want work with community domain. ( 2. domain ). We setup with successfully this link: https://www.youtube.com/watch?v=9zxMUrayFZ8&t=1634s
We was work with perfectly with the video in the link for login.salesforce.com or 1. domain but doesn't work for 2. domain.
Error is:
error image
As seen in the photo we was see a page. But our expectation was that it would working we send redirect_uri. The redirect_uri we sent was to return "girApp://success" with an access_token and instance_url at the end. But we encounter a screen as you can see in the photo. Redirect is not working. Our goal is to access the access_token with redirection within the application after login and authorize.
Lots to unpack here.
***.my.salesforce.com is your main domain, for internal users. ***.force.com is for Customer/Partner Experience Cloud (formerly known as Communities, formerly known as Portal).
developer#cloudspade.com mail work with success on 1. domain but not
work on 2. domain
Out of the box Salesforce is perfectly fine with internal users logging in to community or even 1-click switching over from internal SF to community. Collaboration and all that. Your administrator probably marked only certain profiles / permission sets as community members, you'd need to check config. But it's possible to use the community login page, you guys just chose not to.
communitytest#cloudspade.com mail work with success on 2. domain but
not work on 1.domain
Yes. Community members must use community login page. They can't use generic login.salesforce.com, test.salesforce.com or your branded ***.my.salesforce.com
works perfectly with (...) login.salesforce.com or 1. domain but
doesn't work for 2. domain
That's because most of the time the community login url must be full. Just the domain might not be enough for login because you can have up to 100 communities under same domain. You probably saw the example when you were enabling communities (Setup -> Digital Experiences -> Settings)
Go to Setup -> Digital Experiences -> All sites and write down the url you'll see there. It'll probably be something like ***.force.com/myportal. That means that for API login you might have more luck with ***.force.com/myportal than ***.force.com.
Stop reading this answer now and go read Sitecore - How to get User ID if the user was logged in using external identity provider (Salesforce SSO). Play with that OpenId Heroku app, once you get this to work with community user in the browser - you'll know which url to put in your react app. React developer might "like" this link too: https://gablesinsurancerecovery.force.com/.well-known/openid-configuration
It's kind of written in this article's footer: https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_endpoints.htm&type=5
Instead of using login.salesforce.com, you can also use the My Domain,
Experience Cloud site, or test.salesforce.com (sandbox) domain in
these endpoints. For hostname, use the My Domain, Experience Cloud
site, or custom URL
Below is my code to popup and login through MSAL.
var app = PublicClientApplicationBuilder.Create(msal.ClientId)
.WithDefaultRedirectUri()
.WithTenantId(msal.TenantId)
.Build();
var result = await app.AcquireTokenInteractive(msal.Scopes).ExecuteAsync();
Code above works when it's running on my local machine.
And below is my settings in Azure AD. Its working when I set it to localhost:5000
But when I set the localhost to 'myWebAppUrl' which is hosted on Azure Virtual Machine. MSAL won't popup. And it will just return "The operation was cancelled". Anything I missed here?
Please check the below points.
In azure ad,the reply URL must begin with the scheme https, unless using localhost. ex:http://localhost:5000
Else you can use something like https://yourappurl and don’t forget to Grant admin consent
Under Permissions for the scopes you have in azure ad.
Please check Redirect URI restrictions
Apps that use system browsers: http://localhost
Apps that use embedded
browsers:https://login.microsoftonline.com/common/oauth2/nativeclient
For Node.js, you can use msal://redirect
Please check Add a redirect URI section and Client application configuration (MSAL) | Microsoft Docs
And check if you can use confidential client to your app
.
Some authentication libraries like MSAL.NET use a default value of
urn:ietf:wg:oauth:2.0:oob when no other redirect URI is specified,
which is not recommended. This default will be updated as a breaking
change in the next major release.
Other references
Instantiate a public client app (MSAL.NET) - Microsoft identity platform | Microsoft Docs
Initialize MSAL.NET client applications - Microsoft identity platform | Microsoft Docs
I am trying to add a cognito auhtentification to my load balancer following https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html?icmpid=docs_elbv2_console.
When I setup the authentification process, I have only the "oidc" type, but I expect a "cognito" type :
When I try the rest api, I have the same problem
Action type 'authenticate-cognito' must be one of 'redirect,fixed-response,forward,authenticate-oidc'
cognito is not available.
Am i missing some permissions ? I am an AmazonCognitoPowerUser
I had the exact same issue on region eu-west-3 and it's probably a bug at Amazon that costed me a day of my life.
Good thing is you can actually configure Authenticate OIDC to behave exactly like Authenticate Cognito:
Issuer: https://cognito-idp.eu-west-3.amazonaws.com/[pool-id] (make sure to use pool-id and not pool-name)
Authorization endpoint: https://[pool-name].auth.eu-west-3.amazoncognito.com/oauth2/authorize
Token endpoint: https://[pool-name].auth.eu-west-3.amazoncognito.com/oauth2/token
User info endpoint: https://[pool-name].auth.eu-west-3.amazoncognito.com/oauth2/userInfo
The other info to fill should be straightforward.
Make sure to select your scope(s) in the advanced settings and to allow HTTPS outbound traffic on your load balancer security group.
The Callback URL of your App client in Cognito should be:
https://[CNAME]/oauth2/idpresponse if using a custom domain to access your final app
https://[DNS]/oauth2/idpresponse if using the load balancer DNS name to access your final app
I had the same issue, I was on eu-west-3,
By switching in eu-west-1 or us-east it works perfectly,
I guess the option isn't fully deployed yet
I'm attempting to setup a prototype API using nodejs that uses 3Scale's API management.
I've been able to find their plugin intergration code, which is as follows:
var ThreeScale = require('3scale').Client;
// keep your provider key secret
var client = new ThreeScale("X");
// you will usually obtain app_id and app_key from request params
client.authrep({ app_id: "Y",
app_key: "Z" }, function(response){
if(response.is_success()) {
// continue
} else {
throw new Error("not authorized " + response.error_message);
}
});
Which makes some sense to me as part of a server module. But, I'm not sure where the client's credentials are in that equation....
I see it as the client is pointing to your app, and here's the password for the app...but what about the username/password for the actual client!? where does that get checked?
I feel like I'm not grasping their architecture (possible because it's my first real node project and definitely my first time using 3Scale)...
Further, what's a client's request then look like?
in 3scale system app_id and app_key (in this authentication method) kind of represent the user's (i.e. developer's) credentials. This is due to the fact that every user can have more than one application and one application belongs just to one user, so you don't need user credentials. The credentials are checked on the 3scale system side and if authorized, they report the usage and forward the call to your API.
provider_key identifies your account (API owner) and you have to keep it secret (if someone gets it, they can impersonate you).
Did you already check the 3scale's support site? There are many useful information on the system architecture, some tutorials on integration, etc.
You can check them here: http://support.3scale.net
btw. the node.js plugin is a community plugin. You can also try integration via nginx reverse proxy.
We have our own web server hosting our website that is open to the public outside of our network.
I have a request to make our "Internal Postings" link on our Careers page to authenticate the user against our network's Active Directory list.
I currently have it setup so the link hits a page inside the directory structure of the website, and this page's folder is set to "Integrated Windows Authentication". Anonymous access is turned off for this page. If the user is authenticated (ie: logged into our network or supplies proper credentials) it passes them on to an external careers website which hosts our job postings. If they fail to authenticate, it displays a custom 401 error page.
This works fine, but there is a problem with it. Using IE, people cannot just enter their username. They (of course) are required to enter the domain name as well. Unfortunately the default 'domain' is set to the URL of our website (www.xyz.com/username). I would like it to automatically choose the name of our internal domain (aaa/username) but am unsure of how to do this.
Another option would be to use LDAP and a little ASP scripting to authenticate the user. I have this code already, but am unsure of the security consequences of doing so. Basically, the page will be setup for anonymous authentication, and if the user isn't logged into our network, they will be prompted for a username/password using standard textboxes. This is then passed to an ASP script that does an LDAP lookup against our Active Directory. Is there any security issues with this method?
Which method would you choose to do?
Thanks.
EDIT: It seems I cannot authenticate to ActiveD via LDAP using a username/password combo. So forget about that option.
My question now is, how can I change the default 'domain' that IWA uses? Is that at all possible? IE seems to default to 'www.xyz.com\username' (my website) rather than 'aaa\username' (my domain name). Of course, www.xyz.com\username fails because that is not where our ActiveD resides... Is this possible? I want to make it as simple as possible for our employees.
You cannot authenticate an user with a script that looks up the user in LDAP. You need to know that the user is who it claims it is, and the only way to do that is to let NTLM/Kerberos authenticate the user (ie. establish proof that the user knows a secret stored in the AD, the password).
The URL of the web site to the set of sites considered be in the local intranet zone for IE browsers running on the internal network. By default sites consider to local intranet will be sent the current logged on users credentials when challanged with NTLM/Kerberos. Hence your internal users shouldn't even see a network logon box.
I hate to dredge up an old thread, but the answers are a bit misleading, if I understand the question. The thread Remus refers to is about authenticating via LDAP with a username only. As he points out, that isn't possible. But it looks like what Kolten has in mind is authenticating via LDAP with a username and password both. That's a standard practice called binding.