We've got a working salesforce api implementation that gets and sets properly with a production salesforce account. We've recently come across a user that rather than using their production Salesforce to connect to our implementation, has set up a sandbox for a limited trial.
I personally have a sandbox that I can properly connect to. It is not, however, connected to a production salesforce instance.
I'm wondering if the fact that they have a production salesforce instance that they created the sandbox from will affect the API login to the sandbox.
I'm currently receiving a "your salesforce login is incorrect" even though I am absolutely certain the credentials and security token are correct.
If you need any other information, I'll happily include it.
Thoughts?
Login requests for sandbox accounts should goto test.salesforce.com not login.salesforce.com. You should also login through the webapp and look in login history (in setup) that'll sometimes have more information.
Related
Keeweb deployed as self hosted on kubernetes and integrated with gdrive but getting "Google hasn’t verified this app" error.
Nothing in log, follow steps - https://github.com/keeweb/keeweb#self-hosting
means exactly that. An app was created on Google cloud console. This app is being used to request consent of a user to access their data. So a consent screen has been configured.
Any app which requests data of a user, and uses sensitive scopes will need to go though the verification process with google in order to be sure that the app is secure.
Unverified apps
An unverified app is an app or Apps Script that requests a sensitive or restricted OAuth scope, but hasn't gone through the Google verification process. Users of unverified apps or your test builds might get warnings based on the OAuth scopes you're using. This is to protect users and their data from deceptive apps.
I linked Google Drive from my ERP program.
Yet, from last February 20th, I can't sign in from the program.
I checked my domains from Search Console.
However, I still don't get a consent from OAuth Screen.
What should I do?
The below is the image from OAuth Consent Screen.
Unverified apps
An unverified app is a web application or Apps Script that requests a sensitive OAuth scope, but hasn't gone through the Google verification process. Users of unverified apps or your test builds might get warnings based on the OAuth scopes you're using. This is to protect users and their data from deceptive applications.
If you read the page you will see that your application has not completed the verification process as you have requested one or more of the sensitive scopes.
You have also not verified the domain
Only the developer who created the project will probably be able to login and with a limited quota. You need to wait until the application is verified before it will begin work in a production mode.
I have a progressive web application that needs write-access to the Google Drive API for uploading data (media files) the user is creating (either online or offline) in the background while online. It does not really need a server (except for serving the required files, so a static server is sufficient), all of the work could be done on the web application client side.
Since uploading needs to happen on the background, whenever the user is online again (using a service worker and the background sync one-shot API), an access token is not enough for my need (the user can be offline/not use the web application for days) and a refresh token is not supposed to be stored on the web application client side, as far as I understand. Even if it were, I would still need the client secret, which means I have to use a server (or keep the secret within the web application client side, which is a no-no) in order to refresh the token.
It seems like the current ways of using the OAuth2 scheme are at odds with server-less progressive web applications, or I might be missing something. Progressive web applications are more like Chrome applications in this regard, I guess, but I have to supply a Chrome application ID in the Google API console for my application, which I do not (and do not intend to) have and Chrome applications use the Chrome identity API for getting the tokens, which I do not intend to use (and cannot).
I am currently using an actual Node.js server which takes care of the authorization step, keeps the access token and refresh token in a database and returns the existing or new access token to the client, whenever asked. The server is redundant here (and requires a privacy policy for this data which I really do not need to store), I want to do everything using client code, without continuously asking for authorization whenever I upload in the background.
Keeping the refresh token on the web application client side and just reaching out to the server for actually refreshing the access token (nothing must be stored in the server side except the client secret, which is fine), but like I mentioned, I understand the refresh token is not supposed to be kept on the web application side.
Is there a safe and secure way to implement this without a server (or with a server that only gets the refresh token and returns it to the client and refreshes the access token by getting the refresh token from the client)?
It's actually fairly simple, depending on the fine details of your use case.
An important factoid is that once a user has granted permission to your app, he will not have to re-grant it. So you don't need to "continuously asking for authorization whenever I upload in the background". However, the only constraint is that the user must be logged in to Google in order to obtain an Access Token. Normally this isn't an issue, but your app needs to deal with the scenario that a user has logged off from Google, and prompt for login.
All the details are here https://developers.google.com/identity/protocols/OAuth2UserAgent
I suggest avoid the Google JS library because (a) it has its own opinions about the UX, (b) wasn't written with PWAs in mind, (c) has issues on mobile, and (d) is closed source so when it breaks (as it does occasionally), your users are dead in the water until Google fixes it. The page above details the OAuth endpoints so you can easily use them directly. This has the side benefit that adding other cloud storage accounts (AWS, Azure, Drop, etc) is just a case of changing the endpoint URL.
The architecture I use in my PWA is to have my PWA prompt once (and once only) for authorization and then store the user's Gmail address in localStorage. I then have a
hidden iframe which polls once per hour for an Access Token, using the gmail address in a login_hint. This means the iframe is never required to present any UX. The only time UX is required is for the initial auth, which is of course unavoidable, and once per session if the user has logged out of Google.
The only other edge-case you might want to deal with is allowing the user to select between multiple Google accounts, say a personal account and a work domain account.
On a broader point, remember that Google didn't create the OAuth spec so there is little they can do to provide an alternative solution. At an abstract level, auth requires one of the user being present, or secure storage for a permanent token (eg on a server or within a secure store such as Android). Even if we invent OAuth 3, that will still be the case.
Our organization uses single sign-on functionality to log into Rally automatically for each user. Wit custom apps I have created in the past which use the Web Services API, this doesn't appear to cause any troubles, however, when a user who has SSO enabled tries to run an app which uses the Lookback API, a login box appears (shown below). Neither the user's SSO credentials or their previous Rally login credentials seem to work in gaining them access to the API.
My assumption that it is SSO causing this problem is strictly based on the fact that the few of us with it disabled do not run into these problems, however those using SSO encounter it every time.
Has anyone experienced this issue before?
Jake's team at Rally deployed an update that should have resolved this issue. Don't hesitate to post back if it's still occurring or if there's other concerns.
I recently started a new project using different carefully-chosen technologies, my project is built as follow :
The approach is API-Centric, which means I'm building a website and an iOS app communicating with an API written using Symfony2. I've successfully managed to write my API, and it is perfectly working.
To gain access to the services provided by the API, the main actors (the website users, the iOS app users and the developers) can authenticate theirself in several ways :
Clients can gain access with a login/password couple through the website interface which is communicating directly with the API through AJAX to validate the provided credentials and set a session. So, when someones logs in our website, they have automatically access to the API as well.
Developers can authenticate theirself through the API using HTTP-Basic over SSL, which will as well generate a session and give them access to the services they are authorized to call.
Also, Developers and clients can gain access to the website and the API using their facebook account through the Facebook Connect functionality. This deletes the step where each actor has to create an account on our website.
So basically, the credentials are provided either through HTTP-Basic or using the Facebook Login functionality.
Now that my authentication system is working and that my clients are able to access the website, I would like them to connect to a real-time server when they log in. Like in Facebook or Google+ if you want where the real-time server manages chat and push informations.
In this case i'm using Node.js and the powerfull socket.io library to manage everything that deals with the real-time side.
Of course, the real-time service will need some credentials to authenticate the user since he is authenticated to the Symfony security system with a session but is not authenticated against the real-time server.
A solution I've been thinking about would be to use the PdoSessionStorage in my API (Symfony side) and store all the active sessions in a database such as MySQL or PostgreSQL. Doing so, I would be able to send to my real-time server the session id generated by symfony and check on the database if the session id provided is correct or not. If he is I'll let the user access the services provided by my real-time server and associate his session with an identity.
But I really don;t know if this is a good solution and I would like some more experienced advices on this and on how to deal with this issue.
Note : For some reasons, I cannot implement OAuth even if it could be a solution to solve this issue using a Single Sign On approach.