Well... sort of. The only two officially supported methods are by Basic Authentication and OAuth tokens. That site uses a non-standard API design, so it can't directly benefit from using a Named Credential. "But wait," I hear you say, "you didn't say it wasn't possible." And for that, you'd be correct. Here's what we can do to work within this system's ...
To those hacking MavensMate's source code to keep it alive: I strongly recommend you migrate to official Salesforce tooling, namely the VS Code extensions for Salesforce.
MavensMate's codebase has not been updated nor has it been audited for security since development ceased in 2017. Since that time, several of its dependencies have received critical ...
You're trying to setup / use Service Provider (SP) Initiated SSO. In this case Salesforce is the SP and you've configured an external IdP to provide authentication.
SP Initiated Login works on Salesforce with My Domain. Additionally you will need to set up Salesforce for federated authentication on your IdP, by (at least in case of ADFS) importing the ...
Packaging the connected app allows administrators who install the app to control which of their users can use the application.
Rather than the coarse ability to block or not block an app (seen in Setup -> Manage Apps -> Connected Apps Oauth Usage), you get the ability to control the security settings for the app in a more finely grained manner (seen in ...
The User Agent (UA) and Web Server (WS) flows have two different security purposes. The main difference is that UA is used for untrusted clients, while WS is used for a server application; the WS uses a Client Secret (CS) as an extra authorization parameter to prevent spoofing servers.
The reason for this is that if a server is compromised, everyone using ...
It's my understanding that custom authentication schemes invalidate the confidentiality clause of the Salesforce.com Master Subscription Agreement and thus would violate your TOS.
If you are building an app for the AppExchange, you would not pass security review.
Don't take this as gospel, but if your users 'own' data in Salesforce then they need licences. If however, your users can submit quotes but don't need to own the data as such, then you can use an integration user, i.e. one user you setup and use in the connecting application which submits requests on behalf of all users.
I've created this exact setup using ...
It's possible using the Mutual authentication feature which allows you to setup certificates for users so they are authenticated via a certificate instead of a username/password. Please note that this is not enabled by default in your org and you need to raise a case to get it.
The steps involved are
Contact salesforce.com to have mutual authentication ...
There has been a lot of discussion around speed of development and reusable components and while I do think we get decent marks for that the real promise of lightning components is that for the first time salesforce is opening up access to the presentation layer technology it is using to build customizable applications. The main benefits have not been ...
You can get the session token from the cookie of the browser. The name of the cookie is 'sid'. In Chrome, you can find the cookie by going to settings->advanced settings->privacy->content settings->allcookie and site data and then seacrch for yourinstance.salesforce.com and select the sid cookie and the copy the content of this cookie.
Connected Apps require your subscriber (your customer) to go through a oAuth authentication flow (with a user of their choice) to allow your application to connect to their org. You cannot and should not attempt to cicrumvent this process for a variety of reasons, most of which security based as you hint at in your question. This however does not mean you ...
If you have requirement of call-out to internal Salesforce url from logged in session, Use your code as:
Http h = new Http();
HttpRequest webReq = new HttpRequest();
// replace endpoint url
Support have come back with:
confirmed with R&D that this is not a BUG rather a security update
that is introduced in Winter'15 release
affected customers will need to adjust their integration's to not rely
on a guest session ID
Your token didn't expire, your password did. As an administrator, you can make a Permission Set with the Password Never Expires permission, and assign it to your user account (affects only yourself), or you can change the Password Policies so that passwords never expire (affects all users in your org). You'll never have to worry about expired passwords again....
MavensMate has reached its End Of Life. The connected app that it used to authenticate with Salesforce has been decommissioned, as indicated by the OAuth failure you see.
There is the chance it could be brought back to life if you were to supply a connected app client id to the Node process based on an examination of the core MavensMate package. It accepts ...
You can't actually create a user and specify a password for it so you're going to run into a dead end right there.
It sounds like the real time API will be running on the clients' orgs and you'll be connecting to those to consume data. If that's the case then things are definitely going to get complicated. You can not create a new user in the client org, ...
The key to solving this problem lies in two parts:
Having a dedicated SF User to handle all requests from your 3rd Party to SFDC
Creating your own User DB + Code to that verifies your 3rd Party user credentials. Once verified, they will then have access to the SF User. The extra code you'll have to write is to manage what kind of processes you want to ...
There's two main ways to use 2FA. The first is where you enter a code each time you log in, and the second is where you authenticate the login through a mobile app. If you install the Salesforce Authenticator, and connect it to your login for 2FA, you can then log in simply by pressing a button on your phone after entering your password. Additionally, during ...
Since the page is set as one of the lookup fields on the Site Detail page that page is automatically enabled for the site.
The related list of Site Visualforce Pages on the Site Detail page has a link to the Enabled Visualforce Page Access Help page which has the following:
If you select a Visualforce page for any of the lookup fields on the
The quick answer: if it appears in the User Logins admin report in Salesforce, it's counted.
The longer answer: yes if someone explicitly signs in multiple times during a session, even when they were already logged in, it is counted. So yes you will need to be diligent about this. If it's a web service, what I would do is make it a term of service that they ...
Chances are the Visualforce page in question hasn't been added to the allowed list for the site's guest user profile.
The profile for guests isn't listed with the other user profiles, but found by clicking the "Public Access Settings" button when viewing the detail page for your site:
When you're viewing the profile scroll all the way down to "Enabled ...
This discussion forum thread suggests that you can do this with
Change <instance> to the relevant instance, e.g. na1, and substitute in the relevant IDs.
Salesforce CLI use an access token to connect to your org. This means that even if you change your password or even your username it will still be connected to your org trough your username. If you want to revoke the access permission you can do it by navigating to Setup>Home>Apps>Connected Apps>Connected Apps OAuth Usage and block the Salesforce CLI app.
You can accomplish this with Auth.SessionManagement class methods. The code below sets the isTrustedIp variable based on whether or not the running user's IP address is in the trusted ranges (as defined in Setup > Network Access > Trusted IP Ranges):
Boolean isTrustedIp = false;
Map<String, String> sessionAttributes;
As Joe mentioned above, Mavensmate suffered from a serious CSRF & CORS vulnerability (conceived by @ralph-callaway; confirmed by myself) where any website could make requests against the localhost server. This essentially meant any website you visited could access the auth tokens for your authenticated orgs.
For Example, the following script will ...
The SFDX URL can be used to authenticate to the salesforce cli without needing any JWT Token or using browser to key in the credential .
Infact it is the easiest way to authenticate through CLI. Let me explain how salesforce cli authenticates today.
First time when you login via the CLI, you go to salesforce login screen and key in credentials (if you are ...
One approach would be to encrypt the user's username/password and write them to a persistent cookie. So, in a custom login page controller, you would have code like
// Technically, '^' is permitted in an email address, but most systems disallow it
String data = username + '^' + password;
// Base64 encoded key is stored in a custom setting
Instead of delegating to a human for credentials, you can use the Username-Password flow (where you securely store the credentials and a security token) - here's an example:
Authenticate with credentials stored on your server (the response will be JSON, not frontdoor.jsp)
$curl = curl_init();
CURLOPT_RETURNTRANSFER => ...
You need to:
Set up a Force.com Site
Grant certain object permissions and field level security for each Timba Object to the Site's Guest Profile (Public Access Settings)
Grant access to the TIMBA Apex classes and select Visualforce pages to the Site's Guest Profile (Public Access Settings)
Configure the Timba app to use the site
Take a look at the Timba ...