We're working on updating a Bigcommerce app (Previously submitted and currently live). It just so happens that we need to modify the scopes needed (we need access to products now).
Once changed, will our app go into pending mode and require resubmit? Will there be down time? if so, what will happen to current users that have the apps installed will they be able to use the parts of the app that use the scopes we already have permissions for?
Also, Will the current customers be prompted to approve of the new scopes the next time they try to start our application? how is this done?
After a change on the BigCommerce end, this is something you are able to do within the Developer Portal There's more info available about the scope update flow here.
Related
I am new to Shopify and exploring options to run a streaming service. I want to build functionality through which I am able to limit the number of users concurrently login through a particular account.
That is if say 4 users are logged in through user A it should not allow 5th user at the same time (Based on plan) as people share their login credentials. Does Shopify provide this functionality or any good recommendation of any such app?
You can check this app . This is solving similar problem not sure how they are doing it though .
You can configure this app easily and set your custom banner for 5th user (In your case) or also force log out the first user in case of 5th user attempts to login.
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 can see many related questions on SO, but none that answers exactly what I'm confused with.
I'm using Google Calendar API in a .NET desktop application that allows user to provide his/her username/password, logs in on his behalf and adds some events to the calendar. Now I want to do exactly the same thing for Tasks feature. I'm trying to use Google Tasks API for this, but have been told that I need to do some OAuth kind of authentication, and even before that, I need to go to my gmail account and set permissions and get my project "key" to enable it.
Now does every user of my application need to do these steps in their Gmail account? Or do I need to do this in MY gmail account once and then my application code will be able to use the generated project "key" to enable my users to add tasks to THEIR gmail tasks list?
Figured it out. For anyone having a hard time understanding this, here it is:
The "key" generation step needs to be done only once per application, not for each user who's going to use your application. To generate a key, login to your Google Account and go to Google APIs Console page. Click API Access button and that's where you can generate keys for different kinds of applications like browser apps, desktop apps, Android apps etc. After registration, you'll need to take Client ID, Client secret and API key from this page and put them into the code. Sample code (.NET) for task creation and several other Google features is available here.
Once your user runs your application, he'll be taken to his Google account in his default browser where he'll be asked if he wants to allow this application to write to his calendar/tasks list. This page will display your logo and description text too that you can provide at registration time. Once allowed, this step won't be required again in the next one hour (this may be adjustable, i don't know yet).
I already submit a application on app store which have price $6.99. Now I am submitting new version of this app. Here I want that iPhone user, which already installed this application, should pay $.99 for this update and new user should pay $6.99
Is it possible to charge extra amount for existing user for update ? Please suggest
No. Updates from the App Store are always free. If you wish to charge for additional content, you can use the In-App purchasing system.
Otherwise, your only option is to create an entirely new App for major updates if you wish to get more money from your users.
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).