Background:
I am making an app which will be a public app and will put it on Shopify App Store.
I have completed with the OAuth process and I get access_token and scope in return which is good. I can now use this token and send API requests with X-Shopify-Access-Token in the header.
But, for my database design, I need the user details as well, like user ID or email ID for example. However, I read the docs(scroll up a bit) and it suggested in the caution section that email address is not reliable to identify the user(merchant). I also gave a read on access modes which is online and offline, and in my case, I would need an offline access token.
Question:
How would I get a User ID from Shopify during app install so that I could uniquely identify each merchant?
One of the reasons I would want to have this is because a single merchant could have(or see) multiple stores linked with my app and I wish to show them details for each store under a single user account.
When a merchant installs your App, during the oAuth flow, you are presented with the shop name. That is unique, and will always be present for incoming calls to your App from Shopify.
You do not mess around with email, or user ID's. You simply persist the access token you got in your data store, with the shop name.
If you wanted to group by a merchant name, you know each Shop object provides the shop owner details. So you can always dig those out and store them along with the shop name, allowing you to show one merchant, many stores.
Related
1.What is the major difference between Shopify partner and Shopify admin?
2.How to connect both?
3.Reason behind 2nd question is
only in partner site we can see the status of API health and
I can only see order/customer/product details in Shopify admin not in partner. In my use case I want to see order/customer/product details and also want to test GDPR webhooks. How it is possible?
A partner account can be created on https://en.shopify.hk/partners. When you create a Shopify Partners account, you gain access to a Partners dashboard, and you will become a Shopify Partner. By creating a partner account, you would become an admin of the partner account will be able to:
Create Development Stores: those are stores that you can create for free and use them to develop new Shopify themes, apps etc. Development stores do not have a monthly recurring hosting fees. However, they are password protected, and cannot accept any form of payments as the purpose is to either develop and/or test themes and apps. After setting up a development store, you can also change it to a Managed Store by transferring ownership of the store to a client who will then pay for the hosting, and make the store functional. This client will then become the admin of the store.
Create Managed Stores: those are stores that you create to sell; you pay a monthly hosting fees depending on the pricing plan you select, and users will be able to make payments through those stores.
Develop public/custom/private apps.
Link to specific stores: if you want to update the code on another merchant's store, which you did not create, you can click link the store by adding a Managed Store, then input their store URL, and send them a Collaborator Access Request. Upon accepting your request, their store would appear in your partner dashboard and you can access their store dashboard to see orders, customers etc. On the list of stores in the partner dashboard, you will see a Log In link to login to the dashboard of each store individually.
Add members: you can add members to your Partner Dashboard and give them different roles, and access to specific stores linked to your partner account. This way, if you want multiple developers to work on a store you have access to, they can access those stores (although the store owner will not know who is accessing, they would only know that it's being accessed by your partner account specifically).
For each store linked to your partner account, you will see whether it is a Development Store, or if it's a Managed Store, you will see the plan chosen. For Managed Stores, you can also click on Actions and completely Remove access for yourself by unlinking your partner account from the store.
On the other hand, a Shopify admin account refers to an administrator account specific to a store. For example, if you own a store, you would be the store admin. Each store can only have one admin, and a selected number of staffs. The Basic Shopify plan can only have two staffs. However, each store can have unlimited collaborators which mean, each store can be linked to multiple Partner accounts. Partner accounts only gain access to what the store administrator provides them access with. When you send them a collaborator request, it asks you if you would like to request access to everything, or only specific parts of the store, such as themes/apps only.
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.
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'm working for a company that displays content on big screens located on public places like GYMs or waiting rooms.
One client asked app that shows Instagram content from celebrities accounts, so I created one using the Instagram API.
The problem is that the app is in sandbox mode and it gets blank data.
It seems I can only show media from sandbox users (not Beyonce), when I submitted for review it was rejected because it doesn't meet the requirements.
Is there a way to make it work?
During tests I used a valid access token I found on internet, but I don't think that is a valid solution.
You are correct, when app is in sandbox mode you are only able to see data on Instagram from sandbox users which you have set in advance. You won't get any public data on Instagram in this mode.
According to the API, your app doesn't have the criteria required to get approved.
From the Permissions Review page:
Valid Use Cases
We will approve submissions of apps that fall into these use cases:
To help individuals share their own content with 3rd party apps
To help brands and advertisers understand and manage their audience and
digital media rights
To help broadcasters and publishers discover content, get digital > rights to media, and share media with proper attribution
They also listed use cases of applications that won't get approval and it seems like your app matches one of them:
Here are some examples of scenarios that will not be approved:
One-off projects. If you are an agency building websites or other integrations, note that we don't grant permissions to clients created
for one-off projects. If you are interested in building a product,
platform, or widget that will be used as a service across multiple
projects, then you may submit a single client_id that you can use
across multiple projects
...
To get approved you should modify your application to correspond with criteria, perhaps build multiple projects?
You can also try to pull down the data from this URL: https://www.instagram.com/<username>/media/
For Beyonce account, use: https://www.instagram.com/beyonce/media/
Lastly, the access token is unique per-app, so you can't be using a random one. Here is a tutorial on how to generate access token for your app.