I want to develop a front-end in Javascript (possibly with one of the fancy frameworks around such as AngularJS) that consumes the REST API of my Salesforce org.
I don't want to embed my project in Salesforce technologies, so basically
no Visualforce pages
no Force.com Sites
I do want to write my own front-end on a separate server that just makes AJAX calls to the Salesforce back-end.
In addition, I want the application to be accessible for any user, even if he/she does not have a Salesforce account. So the AJAX calls should not require that the user logs in on Salesforce. I want anonymous users to be able to retrieve public data from my organization and create new entries when it is useful (in the case of a survey for instance).
Even though these requirements generate some security concerns, I can imagine that Salesforce takes care about the requests rate limits on their API endpoints and that it is possible to restrict the access to the API on a host name base (e.g., only requests with origin host my-trusted-domain.com should be allowed, send a 403-Forbidden otherwise). I would be surprised if SF does not provide such basic features.
How would you proceed? Is there a minimal Javascript code that works out-of-the-box on any domain without getting into troubles with CORS?
All REST API calls to Salesforce must be authenticated. If you want anonymous API access then you will need to proxy authenticated calls through a server (like on Heroku) that adds the auth token. Or you can use Heroku Connect to expose your Salesforce data to a Heroku app as a Postrgres database.
If you go the REST route then checkout the ForceServer and my CORS Proxy for Salesforce. Both are not setup out-of-the-box for the anonymous access you are looking for but could easily be tweaked to support that use case.
BTW: When allowing anonymous access to your Salesforce data through a proxy make sure you are dealing correctly with security and request limits.
Related
I'm looking a way to securely share a token between one webapp with the front-end of a second webapp.
Environment details:
webapp.local: A PHP webapp that stories some data that are restricted to specific users. This webapp is accessible by VPN only.
otherwebapp.example: This is a Zendesk instance, it allows us to create a plugin (HTML + JavaScript) that is loaded on the client-side.
Notes:
webapp.local and otherwebapp.example use different domains (they aren't sub-domain).
otherwebapp.example is not able to access the webapp.local. But the front-end will be able (the user are connected to the VPN).
I did some research, and found some options:
HTTP Coockies: the "SameSite" need to be "None" (reference), is it a secure option? I did some tests and seems that they need to be on the same sub-domain.
JS postMessage: It will need to open a popup or a iframe, I did some tests but still trying to make it works.
The question is:
Is there a best practice or another way to share a sensitive data (token) between a webapp and a front-end located on other domain/app?
I think there is not a fully secure way to do it because you want to handle the share on the client side and that will be always exposed, though you can take a different approach like share a request token via GET param to the second webapp and there call a validation API that validates the origin of the request (should be restricted to the second webapp domain) and also validate the passed token and then return the actual session token.
So, I was looking at building a JS based front-end (probably with Vue.js) when I encountered a problem.
The backend already has OAuth based APIs, where I would need to authenticate all the API calls using an access token. So I went looking for ways to do so and found out that I should use Client Credentials grant.
The problem is that a frontend application would expose the client ID and secret. These can simply be tracked through the "Network" tab of the Browser's inspector. This makes it possible for anyone to obtain an access token and make dangerous API calls (like deleting stuff).
I also found that PKCE flows dont use client secrets.
However, I have 2 problems with PKCE as well:
Authorization is not needed for these APIs to call as these are very adminy (like user management) APIs.
PKCE will also expose the client ID.
Assuming that my understanding is correct, how should I implement the OAuth APIs such that it is secure and does not expose any credentials?
Also, if there needs to be more information, please let me know.
I have a JSP webapp developed in Eclipse as a dynamic web project.
we use a third party web application that invokes my application, I need to validate that only the requests that come from that application are allowed to create a new session in my application.
I´m tring to do it with javascript and thinking , as a last resource, to use a Filter class to know the request origin and define the behaviour.
the problem is that the user requires that the operation is done on the client side, meaning I have to use javascript or similar, I have read about document.referrer on JS, but so far nothing is shown on the console.
Anything that you do in the client using JS for handling sessions wouldn't be secure as it can be easily modified by a malicious user. Also, using the referer or any other http header params would be insecure as they can also be easily spoofed.
If this third party application is directly calling your application I imagine that you have some degree of control over it. Can you access and modify its source code or are you just using configuration params?
Ideally the third party application would use an authentication token on each request that it makes to your application. And these authentication requests as well as all the session handling logic would always be handled on the server side.
I have come across few chat application and the website which I don't know how these things work. can someone tell me how these application works in the website.
I have seen some website with a chat widget for helping the customer for respective to their business. On signing in these application, a script file is send to email, when it is pasted over the website. Automatically a widget is created. And this widget and the application is connected externally.
Sorry, if my question is not clear. I will give some links of application and website which give you some idea what I'm trying to ask.
Website
http://www.a1000yoga.com/
http://www.voyzek.com/contact-us/
Application
https://www.zopim.com/
https://my.livechatinc.com/
What you mean is called providing Web API,
Wikipedia's definition of Web API is :
A server-side web API is a programmatic interface consisting of one or
more publicly exposed endpoints to a defined request-response message
system, typically expressed in JSON or XML, which is exposed via the
web—most commonly by means of an HTTP-based web server. Mashups are
web applications which combine the use of multiple server-side web
APIs.
In brief, They implement their service in their servers, and let you access their services by HTTP requests.
You sign up in their website and they generate a API token(a random string maybe), then when you want use their services, you send them your requests with your API token as authentication or identifying mean, and they process your request throw their application and with your data on their servers, and send you respond.
For example when you use this messaging services(or Captchas, Ads networks, etc), they provide a piece of Javascript containing your API code, then when someone views your web page, the code will send request with your API token to API provider servers and they process data for you.
You can then access to your data through their website, another API, email or etc.
We have developed multi-client application i.e. the business logic resides on server side and the interfaces are exposed via REST API and mobile/web-client consumes the APIs.
The application allows different users to signup/login to get user specific data. We use http digest based authentication and a token mechanism to keep track of user state.
However, we want to restrict the access of APIs i.e. only our registered mobile/web-client could access them. So we introduced a second layer of authentication and named it service layer authentication. We are using our custom token based system just like we did for user authentication. The over all flow for mobile clients is good enough for us but for web-clients we have issues. If we embed the user credentials in Javascript, anyone can extract those credentials and consume the APIs.
In summary, all we want is to identify/authenticate the Javscript based web-client upon ajax calls.
P.S. Just for clarification, with web-client I mean our web application not the browser.
I believe you are looking for a credential exchange, where the user provides hard credentials once (such as username and password) and then recieves a scoped token which is used as an authentication mechanism on subsequent requests.
Disclaimer: I work at Stormpath, we offer user management as a service.
If you are building a Single-Page-App (i.e. AngularJS) I would recommend my recent writing on the subject: https://stormpath.com/blog/why-we-rebuilt-with-angular/