I have a client that is using a third party custom membership database for a an online service that currently collects member data and payment information. They recently switched their landing page to Squarespace where non-members can find out more about their service and then they are forwarded over to the database site. My clients would like to use the eCommerce option on the Squarespace website, so my question would be does anyone know of how to integrate payment and membership information to be directed from Stripe or SquareSpace to a third party membership database?
Unfortunately, Squarespace doesn't offer the ability to "call out" to any 3rd party services, server-side.
Having said that, I see three ways to accomplish this.
Use client-side Javascript injected into the Order Confirmation
Page. That means that the server on the receiving end would have
to have CORS support (allowing such a request to come from your
Squarespace site) or it would either have to provide its own API or
support JSONP.
Use some type of service to parse the email that you receive when an order is made. When an order is placed, users of your Squarespace site with admin or store-manager permissions will receive an email. If you have a service that can "watch" for this type of email to come in (or run every X minutes) it is possible to parse the email and then take some kind of action as a result. One drawback here is that Squarespace doesn't allow much customization to emails, so if Squarespace heavily modifies the format of the email, it could break your service. Zapier is a service that might help you accomplish this approach.
Because any activity from your Squarespace "store" will generate activity within your Stripe account, it may be possible to use Stripe's Events/Webhooks service to call out to your database service. I have not attempted this, but it is something that may be possible.
Of course, these all assume that there is an "endpoint" URL associated with your membership database that can receive the data and handle it accordingly.
Related
I'm creating the user authentication in a web application, and I want to use Identity Server for resource protection.
The sample code and documentation shows how the user logs into Identity Server after creating an account for it. That is to say, they log in with their own Identity Server account. The quickstart even provides a UI.
But I don't want users of my application to have to log in to Identity Server, an external website. I want them to only have to log in to the web application.
So how to proceed? It just doesn't seem at all clear from the documentation how you're supposed to handle this scenario, which I would have thought would be the most common.
Do I just use a pre-defined API scope and user for token validation, holding for all the website's users? That doesn't seem to be very secure given that any user of the website or anyone with the client name and secret would have a valid token. Not sure what the point is in having the security if it's that easily worked around.
Or do I interact with my Identity Server instance somehow after the user is registered in the web application, and store the new user in a database? I can't find any mention of this in the documentation . It all seems to be very muddled to be honest.
Please could anybody shed light on some of this? What is the "standard" approach here? To have the user sign in to the external Identity Server website? That seems a great way to annoy your users.
If you only have one application and you don't intend to add more applications that needs to share users, then you should look at ASP.NET Core Identity
The whole point with OpenID-Connect/IdentityServer is to delegate the managing and handling of users/passwords (authentication) to a central entity. So individual applications don't need to deal with that complexity. IdentityServer is useful when you have multiple applications or if you have more complex integration needs. It is also perfect if you need to customize it to your own needs. If you don't need the customization part you can also outsource it to someone else like Auth0 that give you an IdentityServer like experience as a service.
We want to use OKTA for SSO but need to know if this is Synced in both ways?
In case if we are making any change in Salesforce side for User , will this be updated back to OKTA, believe not and this would need API calls.
Someone Please confirm.
Pls share the OKTA API wsdl or Link for Salesforce call outs.
Thanks in advance.
This is tricky, ultimately something has the be the master of a Users profile. Okta can push almost any record to salesforce, no problem, and it can import changes from salesforce. But, which source is authoritative ?
What I have done in the past, is I used a (I'm not a salesforce admin) trigger, so when a Users profile was updated in Salesforce, it would make a web service call to update elements of that users profile that needed to be immediately sync'd with Okta.
In this situation, there were people in a call center, and if someone updated their subscription service, they needed that to get pushed to Okta immediately so they could have Okta update that users profile in other downstream systems.
Okta uses rest, not WSDL, but you can easily build a proxy service to accept them, and convert them in to JSON Rest calls. Everything you need is available on https://developer.okta.com (including a sandbox if you need it).
There is also a postman collection, so you can get familiar with the Okta APIs. Here is the link to that: https://developer.okta.com/docs/api/getting_started/api_test_client
I have a google business apps account.
My requirement is to scan all emails of my support email and process them.
This has to be done on the server side without any manual interaction.
I am able to make this work with IMAP, but i am looking at making this work with Google API.
This doesn't work with the Google API unless i do manual client consent.
Or i need to use the service account, in which case i have to get a domain wide access although my requirement is only for one email id. This is against my company's information security policy hence cannot use this option.
Require help on how i can use Google API to do the integration between my server and gmail server at a individual email account level. Any suggestions?
We would like to connect a salesforce user to another salesforce user in another org without any user intervention from a service.
We have tried SAML Bearer Flow (using Remote Access Application) to connect to salesforce to retreive Access Token for one of our product. We are referring to the follwoing article.
http://help.salesforce.com/help/doc/en/remoteaccess_oauth_SAML_bearer_flow.htm
As referred by the SF article for this flow, it uses a previous user authorization to connect and retreive Token. In case the user (for whom Token is requested) has not already authorized the App, SF takes you to the Authorization page first and app will get the access token once app is authorized. This is working fine too. However it has this painful step of users authorizing the app before we can use this flow for the product. It would be good and simplified if this step can be done once for an org and the article does mentions that either User or Admin can authorize the app. However I am not able to find how an Admin can authorize the remote access application.
Does anyone knows and can guide how can an Admin authorize an App or is thre any other way we can achieve our requirement. Any thoughts will be really appreciated.
OAuth1 and OAuth2 require user intervention by design. Anything you do to defeat this would be circumspect and not best practice. You could make it easy on the user, but you will always have the initial "Authorize this app" message.
If you are trying to make it easy for the user to login to either org, then you may want to consider a hub-and-spoke SSO solution. See this doc.
If you are trying to pass information between two Salesforce instances, then you may want to consider Salesforce2Salesforce, or outbound workflow. However, this is done at system context, not user context.
If you want to maintain user context and security, you should consider the new Salesforce Canvas API. Canvas allows you to call an outbound service, and pass credentials to the service so that it can communicate back. There is no reason the foreign service could not be a Salesforce instance.
I'm pretty new to SalesForce and their Apex language. I've been reading some documentation and tried the integration between Google and SalesForce.
I'm wondering is it possible to emulate an auth token from google to SalesForce?
I'm trying to read a google spreadsheet and then fill up a SalesForce object automatically. The user login will always be the same/universal for this spreadsheet, so I have the credentials required to login.
I am working off of the sample that requires a visualforce, and I'm wondering how would I automatically do the session id token that the google spreadsheet API requires.
Any ideas?
The old-school, hard way would be to send a login() call to the API (available through SOAP messages). Salesforce API is well documented and plenty of examples are available (both in programming languages and for raw XML requests/responses).
But I have no idea what possibilities you have from Google side, if it's only JavaScript then you might not be able to send and retrieve AJAX-like calls to another domain...
Recently another option emerged and that is REST API (no SOAP needed). Looks more promising and easier in my opinion. Quick intro is available here and you'll find more documentation on the bottom of the page.
Last but not least - 2 interesting links:
http://code.google.com/apis/gdata/articles/salesforce.html for some integration tutorial
and built-in integration offered by Salesforce: http://www.salesforce.com/assets/pdf/datasheets/SalesforceGoogleApps.pdf
I've used custom settings to do this. Use OAuth to get a token for Google, then store that token in Salesforce custom settings (Setup-Develop-Custom Settings). You can then retrieve the token for callouts to Google from that custom setting for any user needing access to Google Apps. The downside is, every user will authenticate as your custom setting token user. The upside is that they won't need to individually authenticate. Custom settings are retrievable via Apex using a simple getter, and live as Apex-like objects.
Also keep in mind, Google requires each service to use it's own token. So, if your user wants to use Calendars and Spreadsheets, that's two separate tokens that will need to be stored and retrieved for the callout.
I generally allow users to create their own authenticated session tokens via OAuth if they want to do that, then failover to the custom settings to get the general admin token if necessary.
Are you trying to log into Google Apps from SFDC? There are options for Google Apps within Salesforce, go to Setup > Administration Setup > Google Apps > Settings. I've not used this and it requires some setup, but thought I'd point it out. Aside from that I can only blurt out OAuth (getting users to authenticate with Google from within Salesforce when trying to access Google Apps) and SSO (which I know can be used to authenticate from an external system, though not sure if it works the other way).
Look into the "Named Credentials" menu in salesforce setup.
There, you can store auth credentials for the services accessed via Apex:
"A named credential specifies a callout endpoint and its required authentication parameters. When setting up callouts, avoid setting authentication parameters for each callout by referencing named credentials."
a username/pass combo can be used, or a certificate, or an AWS signature, and there is a JWT option..
Help docs: https://help.salesforce.com/articleView?id=named_credentials_about.htm&type=5