We are developing a web app that has users and payments. We need to use it ourselves and we need to allow other companies to use it as well. All instances of the app must use the same database and the same payments account. And it's preferred that each front-end is completely separate.
Here are the ways I can think of:
1) Use OAuth. This is a perfect approach but I don't think each front-end can be completely separate - in other words each app instance would link to the same password and payment forms and then redirect back to the app instance when the user is done with the form.
2) Just give the other company the whole app and let them deploy a completely separate instance. The downside is that we would need to give them our database and payment credentials.
3) Load the front-end of our app into an iframe on their site. Is this even possible? If so it seems like it would meet all my requirements but it seems a bit hacky...not sure of all the drawbacks.
Are there any other options that would allow for the same database and payments account and completely separate front-ends?
Do you want the other company to use your company domain or sub domain or their own domain.?
Your company domain
In this case, create a separate login page. Once user is loggedin, create a custom UI for the logged in user and show the pages for user and payment. It is single UI and it can render based on the user preference like custom font, logs etc.
Company Subdomain
This is a popular model used in Software as Service business. Based on the subdomain, create the custom page and this page will access the services with cusomter id. You can also provide a module for the customer to upload the images, select the font etc.
All the services and transaction will have customer id and easy to track.
Customer domain
Expose the user and payment info as restful webservice and let the customer to create a webpage and use the exposed services.
Related
I have developed a Shopify app, I wonder if we can perform the following functionality :
when a customer has logged in to his account on the store I want to also log him into my app, in another word I want to make a customer account is the same as his account on my app.
One thing you know. A customer logged into a Shopify store has a visible ID to Javascript. You could thus use an App Proxy to securely pass back their ID to your App. Using that ID, you can offer functionality to that customer, in your App. As long as you restrict access to the Proxy, you'd be A-Ok security wise.
If you wanted to allow access to the App without Proxy calls, you'll have to put into place your own security, which as we know from experience, will likely be weak and or a calamity. Most people should never roll their own security patterns. If they login to the App, without Shopify Plus Multipass, you cannot log them into Shopify. So you have no other options AFAIK.
I am trying to make a plan to update my client's shopify stores by building Shopify app or using external library. Basically, I want to provide my clients with some convenience by automating the inventory update, order process and extra stuff.
For now, I have only two scenarios.
Whenever my wholesale inventory changes, i want to update my client's shopify product list to be updated (quantity, price and product description) accordingly.
Whenever my client(shopify store owner) receives an order from his/her customer, i want the order information to be automatically transferred to my server.
If possible, I want my clients to be able to integrate with my application without any tech knowledge. I have looked into the Shopify app (public/private) and some external API(java), because I am a java developer.
I checked Shopify Java library which requires api key and password to be able to access shopify owner's store for product/order access, but I am not sure how user-friendly this approach is in terms of Shopify owner's side.
For Shopify public app, I am not familiar with it, so I am not sure how much I can do with it.
Could somebody provide some details about pros/cons about these approaches?
Thanks.
All you need to know is that with Shopify, you can connect to their shop using standard HTTPS. Even better, it's all GraphQL now. As for credentials, Shopify is fully modern and offers you two methods of getting credentials.
Your merchant client can create credentials with permissions right inside their Shopify Admin -> Apps. They give you the keys, you're in business
You get them (or you) to simply click install your App running at some HTTPS address, and you use oAuth to get the credentials.
Either way, makes no difference to the actual code you write to interact with their shop and deal with inventory, sales etc. You do not need to make your App public in the sense of App store, so you can use your partner dashboard to create an App and oAuth install, or like I said, use the private App way.
The company I am working at offers a web based calculation tool which has to be paid monthly (a fixed price for a license).
Normally, users go to our website and authenticate themselves with their credentials and then can use the application. When they cancel their subscription they are not able to use the tool anymore, obviously.
Now another company called us because they want to provide our application for their own clients. We have already fixed that they have to pay a license fee for every of their clients. But there is also a restriction: their users should not have to log in on any of our websites (only on the website of our client). But the web application is hosted on our server and is loaded as an iframe.
Now there is that problem that we are not sure whether our client tells us the correct number of people who use our application wherefore we would like to verify that in some way.
One of my ideas is the following:
Our client has to call an API for every users who would like to use our application in order to submit some information like name or an unique ID of that user
When the user would like to access our application, an ID parameter is appended to the iFrame URL
I think that this is not a very good solution because our client could use the same ID for every access and pretend that only one users uses the application. By saving the ip address and id of the accesses it is possible to determine fraud in some cases because ip address will not change frequently.
We even do not have to know WHICH user accesses the application but only the NUMBER of users per month.
I am interested if there is a cryptographic solution where it is hard to cheat. Something like an authentication method which does not require any interaction of the user.
Well you can't. You should require the partner to issue a token for each user so you know they came from the partner.
You could have the partner call an api you expose to issue a one time token for a user and specify user id and IP. You could alternatively have the partner digitally sign such a login request.
If you bill the partner per user, and the partner decitfull he could claim less users.
You can fingerprint the users, you can give long term coockies, you can check IP and fonts installed etc. These will allow you to detect most types of fraud.
If you give a declared userId a cookie and then see him again without it, you assign him a new cookie and then later see the first cookie again while the partner is always declaring same id that is a very strong indicator of fraud.
If I was the decietfull partner I would pair up geographicly close users and merge their IDs. it would look no different from a user with two devices. But this still limits the extent of fraud possible. Two devices per user is plausible. 10 less so.
Find business partners you trust.
I have a requirement to do 3rd party age verification before I ship an order. I'm using a company called EVS for this. They released a shopify app recently, but seems partly baked. It requires a user to enter date of birth when registering for an account and then triggers the verification when the user places an order. The main problem with that is that it's rare for a customer to actually create an account before ordering for the first time -- instead they order first, then shopify emails them to create an account after the fact. Creating the account afterward does not allow the customer to enter DOB.
So I'm planning to implement my own solution. I can use EVS's API to run the verification by sending a combination of Name, Address, DOB, DL# and State, and last 4 of SSN. I have already built a proprietary order management system that pulls in customer and order data, and I can write a client to perform the verification.
I'm less savvy on the shopify side. I need to balance customer friction when placing an order for the first time, against having to do a lot of manual work for verification.
Below are the options I have conceived. Are there any other options? Any ideas for a better solution? Keep in mind I need to verify a customer once. I can tag the customer account as verified, and once verified it's business as usual.
Alter shopify templates to only show the checkout button when a user is logged in. If not logged in, show a "Create an account" button instead. That way the user provides DOB during account creation and the EVS app works as designed.
Set up a separate verification site like verify.my-domain.com. I can trigger an email to the customer upon order creation and ask them to verify. (May have issues with incorrect email addresses or spam filtering.)
If customer is not logged in, or account is not age verified, and they click Checkout, I can redirect them to a page. I can use a form on the page to do the verification. If verification passes, send them on to checkout.
For option 3, I don't know what shopify allows or what best practices allow. Can I use js to pass data to my own server on a different subdomain? Or post the form to another subdomain and then redirect back to shopify?
I'd appreciate any thoughts or suggestions.
You have pretty much summed up all your options, to clarify on them a little:
You can require that customers create an account in the store checkout settings. /admin/settings/checkout
This would work, you could iframe it in too on a custom Page. Or, better, use cross-domain calls or jsonp.
This is a little convoluted and you would have to persist and maintain lot of external state. I'd avoid this
I think a combination of 1 and 2. Turn on "require customer account". Modify the customer account creation page. Implement a cross domain policy with your server which will host custom code leveraging the EVS API.
I'm not sure if you are selling tangible goods or not but with stringent policies on users' age you have to bear in mind that shipping addresses could change. For a tight integration you should look at having webhooks whenever a customer is changed and make sure all their data is still valid since their last EVS approval.
I've been looking into this quite extensively and we've spent a number of hours experimenting with options. Our client in this case is on Shopify Plus so we do have the benefit of access to checkout.liquid.
Our research has led us to believe that one cannot pass the required 'customer note' of the date of birth to the checkout should they be attempting to checkout as a 'guest'. Perhaps because the 'customer' does not yet exist.
Our options have been narrowed down to:
Write a custom backend app that allows Shopify and EVS to communicate directly (XML API on the EVS side) in the checkout process or just prior and then pass the verification status back to Shopify to allow the order to proceed, or append some relevant status marker for the fulfillment department to act accordingly. The EVS app doesn't prevent the order from proceeding, but does flag the customer's age as unverified in the Risk Level panel in the admin. This would be quite a substantial project and by no means low hanging fruit. There is also risk of re-doing a lot of what the EVS app does already and running into they same obstacles they did.
Force customers to register prior to checkout (if not signed in). This seems the most viable approach. The only caveat being that existing customers will not have the customer note (birth date) and we'd need to build a smaller backend app to allow them to append this to their customer account via the Shopify API (this cannot be done via liquid).
These are our findings and I'd love to know more about how you ended up approaching this.
I am creating an arcade website with multiple games. should I generate a single oauth client id for the entire domain or should I generate a unique oauth id for each individual game?
The more interesting question is: What user experience would you like to give users?
If you want to build your brand across each of the games, you'll configure a single project (ZBestArcadeGames.com, for instance) in Cloud console. Users will be prompted to authorize your entire site. Whether you create one client or multiple clients in this case is not super-important, since you can configure multiple redirect_uris for a single client. Users will consent once to sign-in to your site and they can authenticate to every game w/o additional consent prompts. Similarly, if they revoke access to your site, they will no longer be able to authenticate to any game in the site. This may be the typical choice if your company develops all games it hosts.
If, on the other hand, you want to highlight the individuality of each game and allow users to consent / de-authorize authenticating to them individually you need to create separate projects each with its own brand (and in this case you will need to configure at least one client in each project). This may be the typical choice if each of the games is developed by a company and there's no implied trust between the games you host and your company, and you'd not like to sign terms-of-service on behalf of these other companies--you might even want to ask the developers of each original game to register separately (using the redirect_uri for your site).