Is it possible to use the salesforce APIs in a JS application to authenticate users of multiple, unknown organizations that I do not control or have access to and import their account names?
I want users of my application, all of which belong to different companies, to be able to import their salesforce contacts into my application. All of the tutorials I have come across seem to focus on creating applications for organizations that the developer has access to via "connected apps". I assume that creating a connected app will only allow access to that specific organization and that if someone from a different organization tried to authenticate and access their data it would fail? Pointers to the product I should be using to accomplish this are much appreciated!
You have the right idea, to get data from a salesforce org, you are going to need the user with the Salesforce account to authorize your application to access the data. The connected app is basically just a way for you to get the auth code that you need to access that data.
It is possible to define the connected app in one org, and have it be used by multiple different salesforce orgs. The data that one auth code provides access to is limited based on the data available to the user that grants access.
Related
I hope you are doing well!
We are working on a project that consists of 3 projects/websites. It's basically something like a Management Platform for the resources, a Platform to display information and updates, and a Platform to manage both those platforms. (Something like Office365 and PowerPoint, Word, Excel where Office365 is the main application between them).
In our project, we want to integrate a navigation drawer in which the user can navigate to the different application from our 3 websites without having to re-login. In this case it would be easy. However, would there be a way that if the user access the other website from the browser (ex:"www.exameplwebsite.website2.com") we login the user directly if he was already logged in to a previous application from ours?
We thought about local storage however the local storage and cookies accessible depend on the domain we are accessing.
Is there a way to make this happen? Or would using a navigation drawer the only way possible?
(For context we will be using ReactJS)
I think it wouldn't be that hard with JSON Web Token (JWT) for authentication. When you redirect the user from one site to the other do it with a post request and include a JWT token in it. The new site can capture that token and send the token to the browser and the browser can catch it and saves it into its own localstorage.
I can think of two solutions ->
Use micro frontends (Recommended)
If all three apps have different domain names (app1.com, app2.com, app3.com) then you're right you cannot share any token using cookies and local storage.
Here, You can take the login/signup pages and the navigation drawer into one parent app and load all your other apps using micro frontends.
Use SSO
SAML and OIDC are made for this specific purpose but this is a very complex topic. Basically, your users will need to log in once(at someplace like google or OneLogin or your own identity server)
I am building a web application, in which I use Vue 2 (2.6.11) and AWS Cognito for authentication. It all works fine (log in/out, display username, groupuser etc). I used this tutorial for it: https://sanaulla.info/2019/04/20/integrating-amazon-cognito-with-single-page-application-vue-js/
Now. My question is, how could I restrict the access to each Vue component based on my cognito usergroup?
Let's say I have two cognito usergroup: admingrp and usergrp, and inside my App.vue two components: admin.vue and normal.vue (there can be more in future). The admingrp users should be able to access both admin.vue and normal.vue, while the usergrp users can only access to normal.vue.
How could I reach this?
The general answer to your question is that you need to test the groups in the JWT before allowing a user to access restricted parts of your site.
One easy way to do this is to use the Amplify UI Authenticator component for the login flow. If your entire application is wrapped in this component, then every page will require login, and your application code will be able to rely on the user object that the component provides. This should contain the groups returned in the JWT, so you'll be able to test those to disallow access for non-admins on whichever pages you want.
This blog post describes a clean pattern you can use for this, although it may be a bit more involved than you need.
We have a web app that caters to a small set of users that are guaranteed to have an account on Office 365.
To save them from remembering one more password, and to use Microsoft's infrastructure for OAuth, we decided to allow them to login using their Outlook credentials.
It is a react app, we are using the msal library and we have successfully been able to receive the accessToken from Microsoft. (Thus, authenticating the user's identity.)
What I am not confused about now is what I should do with that token:
I need to have my own User database. What information should I store in it? Should I store the access_token as well?
How do I verify the user's identity on my backend server?
Basically, what is the ideal way of managing this kind of a scenario? Wherein a third party authenticator is used (and solely) used to confirm the identity of the user and get the name, profile image and other things only.
Any references to existing workflows or an explanation of the steps involved will be highly appreciated.
Using Oauth2 and Google's API I have set up access with a service account, but am struggling to set up access to a specific folder within our team organization.
Currently I am able to do the method calls I want (list, permissions, copy) but the items in the drive that come are only the get started file. I'm not entirely sure which drive this is pulling from as that doesn't exist in any of the accounts I've set the service up in.
My Questions:
When setting up drive integration using a service account, what is the default drive used and how do I access it via the dev console or gmail account?
Are you able to access Organization/Team folders and add files to it?
Thank you again for the help!
The drive resource used will be the the Google account which generated the service account in the Google Dev console.
A service
account
is a special type of Google account that belongs to your application
or a virtual machine (VM), instead of to an individual end user. Your
application calls Google APIs assuming the identity of the service
account,
so that the users aren't directly involved. A service account can have
zero or more pairs of service account keys, which are used to
authenticate to Google.
Are you able to access Organization/Team folders and add files to it?
If you're application is using a service account to login, yes people you've granted permission can definitely access it and modify the contents depending on the roles you've given them.
You can read more of service accounts in Using OAuth 2.0 for Server to Server Applications.
I have developed a multi-page Javascript web application. My clients have asked me to provide a login page. They do not need anything fancy and requested a single username and password that they can share with those who need access to certain featured within the application. They want anybody to be able to see the application, but only authenticated users can use certain tools within the application.
I currently use an ASP.net proxy page (.ashx file) for handling requests to and from a 3rd party server storing the data consumed in my application.
I've never created a login system and have no idea where to begin. I don't think I need a database for login information because there will only be one username and password.
How could I go about securely storing the username and password to authenticate with the user-submitted login information and enabling parts of the application based on whether a user is authenticated or not?
The good news are that you don't need to build the login system, Microsoft did it for you. This is called the Membership System. All you need to do is expose this API to your end users.
And it's a bad idea to have a single credential for everybody. It is better to assign unique credentials to each user.