I have an app that uses parse.com as backend.
If I want to store information about user's in-app purchases in table there, how can I be sure that some guy is not going to create a simple app where users of my app can log (like in my own) in and write in parse-tables whatever they want (for ex.: that they made in-apps when they really didn't). This info is used to give the user access to app's features so it's important that the user really paid for that.
Don't make the table name public knowledge, so don't ever access it directly from the app, always use cloud code. Pass the cloud code some salted hashed details to verify against, and do the verification on save of any new objects being added toot that table with a before save hook. Drop any new objects which don't pass the test.
Related
I am using laravel to build an app in BigCommerce. I am able to get access token but I need to store that for future requests. What is the best possible way to store the app data for BigCommerce?
I've got this working by creating a DB schema in Laravel where in there are tables like stores, users, app_settings.
Whenever the user installs an app, I am storing an access token and other information like store hash in stores table and user details in users table.
Whenever the app is loaded I could get the store and user information via verify signed request payload. Using this I am able to configure my app settings for the user and store those in app settings table.
So when I create a Webhook for the store, I could get the store hash from response as producer key and accordingly I can find the access token for the store using store hash in stores table.
If you're git ignoring your config.json or .env files, you could store these there. However after speaking with one of our Developer Advocates, I wanted to pass along some best practice advice. :) You may want to consider using a secrets manager for option #1 in your decision here. A secrets manager meaning a tool to safely store these variables like Secrets in Github or Key Vault in Azure.
Also, this resource may be helpful to review for your use case. https://www.codementor.io/#ccornutt/keeping-credentials-secure-in-php-kvcbrk55z
I would like to bring a login with Github and Facebook to my single page web app, the server is under my control.
In this tutorial
https://spring.io/guides/tutorials/spring-boot-oauth2/
they store the client_id and client_secret in a file.
Wouldn't it be more convenient if I stored these 2 in my backend database ?
Let's say someone who's not a programmer would like to register the web app to a new service , he could do that easily opening the database, he doesn't have to crawl into the backend project code.
If not then where should these 2 be stored ?
If you talk about the convenience, storing these in a property file is a good option. By doing so, the properties can be easily loaded into the application during the startup. If you change the values, all you need to do is just restart the app and the new values will be reflected.
I am not sure I understand your non-programmer related comment 100%. But IMO, for a non-programmer, modifying a file is much easier than modifying the DB.
Just to be more clear, the client id and the client secret represents the credentials of your application registered with the social media (like facebook).
Ans yes, you can store these in DB as well. But then, you need to write code to fetch these values from the DB and load into your application.
Does anyone has any experience in next task:
I have ready project with some functionallity (some CRUD and payment functions)
I need to make something like demo mode. Where user can create records and make payments (always successfull, without taking charge), but it should not be recorded to database.
All entered data should be available only for this user and be live only fo
My question is how to make it without making copy of the controllers for fake actions?
I have try to look in to database driver that works with session as storage but have not found anything about it.
I recently noticed the addition of a "Session" object in Parse dashboard. Now, from what I understand, a session uniquely identifies a user to the server. So why would we need such a Session? For the session token? We already have a currentInstallation... so I don't really see the point. Can someone explain and provide a scenario where I would use the "Session" object. Right now they just annoy me by their presence because they take up potential space on the Parse server and I would like to go delete them all but want to make sure that isn't stupid.
The sessions are used by parse to deal with the users (is the user logged?, on which devices?, etc.), and are available as a class as you may want to manipulate them. By deleting the sessions you would automatically logout all your users, so it's a pretty bad idea.
You don't have to use or touch anything about this class, but here are few examples of why it can be useful:
[...] If a user contacts you about his or her account being compromised in your app, you can use the Data Browser, REST API, or Cloud Code to forcefully revoke user sessions using the Master Key. These new APIs also allow you build a “session manager” UI screen where your app’s users can see a list of all devices they’ve logged in with, and optionally log out of other devices. [...]
You can read more about the Sessions on their blog post.
For storing WP7-app-data it would be great if it was possible to use the current users live account. Is this possible somehow? I guess not. The alternative is for me to setup my own server to store the data, which means I also will have to implement account-management and require the user to create a new login and password for my particular app/site. This is not very practical as the user already has a live account on the phone. A compromise would be if I could use the logged in live-account on the phone as some kind of token to validate that the logged in user is who he/she pretends to be, and then store the data on my website. Comments?
This is not possible for security reasons and I wouldn't expect it to change in the foreseeable future.
Allowing applications access to a users live account and be able to interact with content there would raise all sorts of possible issues, particularly around security.
On the phone the users data is sacrosanct and you (your app) cannot interact with it without the user knowing.