I'm trying to move the clients database from PrestaShop to OpenCart. In this endeavor I found that there are some sites which can automate this process but at a fairly high price for what I need.
I just have 200 or so clients and if I can't find a way of exporting their login details to OpenCart I will do them manually but hopefully someone can point me in the right direction, so is there a free or cheap way which would allow me to transfer the clients details to the new platform?
The trouble I'm having is getting the password of my customers, if I could get that then I could manually transfer them to the new site.
You can't get the passwords of your clients directly, because they are encrypted. What you can do is to import them as they are and change the way OpenCart decrypts them.
PrestaShop is using the following encryption:
md5(concat(_COOKIE_KEY_, 'CUSTOMER_PASSWORD'))
i.e. concatenated "key" and "password"
where _COOKIE_KEY_ is a constant from /config/settings.php
In OpenCart the change must be done in the following file:
\admin\model\user\user.php
The other ways is just to let it as it is and your customers will reset their passwords via the "Forgot Password" functionality. You can also send them emails, informing them about that switch of the software.
Related
I'm trying to scrape data from HubSpot using ParseHub but not only do I have go through the login page everytime (which is easy because I've set it up to automatically enter my email and password), I also have go through two-factor authentication, which is not easy because: one, it's randomised so I can't keep putting the same six-digit number in; two: because I only have Google Authenticator on my phone which means it's impossible for me to scrape the six-digit number. Just to note, I am able to get past 2FA on Test Runs, because of the "Step in" feature of ParseHub. This allows me to manually enter the six-digit code everytime. Unfortunately, this feature is not available on the live run, which means the script basically fails at the 2FA stage and no data is scraped.
I've downloaded the Google Authenticator extension to my PC, but I have no idea how to have the same account for 2FA for HubSpot that I have on my phone, be present on my PC. If I was able to achieve that, I'm pretty sure I would be able to scrape the six-digit code.
Any help would be greatly appreciated.
Our client has asked us to build a Shopify site that ties into their in-house customer db (with or without using Salesforce). Is this even possible? Does Shopify support any method of cross-site database querying?
The only thing I can think of to accomplish this is to write a webhook on their in-house server with a simple read-only mini DB query API. However, as that I'm not super familiar with Shopify's more obscure capabilities (and having already spent quite some time sifting through their docs and running google searches on the matter with absolutely zero results), I'm not even sure if this is possible.
Are we barking up an impossible tree, or is this something that can actually be accomplished?
Thank you in advance for any help you can give.
What I have understood from your description is you already have an external database with user login details and you want to use the same for authentication in Shopify. If yes, then it is possible with Shopify Multipass feature. This feature is only available for Shopify Plus plans. From the Shopify Multipass docs
Multipass login is for store owners who have a separate website and a
Shopify store. It redirects users from the website to the Shopify
store and seamlessly logs them in with the same email address they
used to sign up for the original website. If no account with that
email address exists yet, one is created. There is no need to
synchronize any customer databases.
For your particular scenario, you would have to validate user credentials with your external database, generate multipass url and redirect.
Yes your requirement is quite possible. But the method i am going to mention is a hack basically. Below are the steps:
Create Login page/Account creation page in Shopify
When the user does a login/create account you send the information to your server via below methods
JSONP request
Creating a iframe of your domain and passing the information in the iframe
Now, you validate the user credentials at your server
After validating you check if the user is present in Shopify. If not you create the user with a password. API Link
Make sure you save the user password you push into Shopify at your end also.
Now when you have completed authentication of the user, return back Shopify username and password
Create a hidden form in Shopify liquid file and pass the credentials in the respective fields and submit the form and user should be able to log in with the existing password they have!
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.
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 developing an application where I have a section only for paid users where they purchase for the section using the in-app purhcase system in iOS. I know that I need to keep track of the purchase history myself, and this is where the problem begins. I have a database and I am capable of storing users in my database, with a web service interface. How can I create a system where a URL is pinged only when a user has made the purchase.
As an example, I have the URL:
http://example.com/registerUserPremium/userid=123456
How can I get this to be called only when a purchase is made? The most elegant way seems like Apple pinging the URL with a special user ID upon purchase, but I can't find a way of doing it. It is obviously not a solution to make the user call that URL within the app, as it can be cracked/pirated. What is a good way of providing such a mechanism that is piracy-proof. My service is web-based, so if I can get this part done, the rest relies on my server-side mechanism (the user will just send a special key that is stored in its keychain, to the server) so I'll be able to finish the project. In short, I need a way to call a URL only when a purchase is made. What are some possible solutions?
Thanks,
Can.
I see two solutions:
"Server product model" (doc): the appstore contact your servers every time a user makes a purchase. In this case you have all of the information right away.
"Builtin product model" (same doc) in which the application gets the receipt from the appstore. In this latter case you can contact your server special URL, providing the receipt information, and the server can verify that the receipt has not been tampered with asking the app store to verify (it's a simple post, see here).