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.
Related
We have a Firebase database connected with an APP which we want to convert to a website now. Laravel is nice frame work but unfortunately unable to sync the existing database to show up on the website as is. End goal is that any changes through an APP should reflect on the website and vice versa. Existing database include the product price, picture, ability for users to message each other , user authentication. In essence it is almost a complete market place.
If you want to use data from the Firebase Realtime Database in a web app/site, consider simply using its JavaScript SDK in your web application.
Doing so allows you app to directly read data from the database, instead of having to set up a web server in Laravel.
To ensure that your users only get access to data they're authorized for, you'll want to use Firebase's security rules. These are enforced on the Firebase server, so once you configure them correctly, there's no way for anyone to bypass them.
I have a live application for my app,(say at mysite.com). As part of my customer on boarding, I have a demo site at (demo.mysite.com), this is where I show potential customer what the app can do, etc. (Different databases and url). In order manage my system, i created also an admin panel on my live site.
Is it possible for me to control the demo site from my live site admin panel. I need to perform activities like,
After a user signs up on live site for a demo account, I create a demo customer via the admin panel after reviewing the request. Which means I need to access the demo site via controller to make a new "demo" customer model, is this possible? I know that I can make multiple mysql connections from live. But how can I perform Eloquent model operation from my live site?
Should I set up a different set up for my demo site.? Is this over complicated? I can set-up a demo accounts for my potential customers on my live site as well. I chose this set up thinking that it's safer in terms protecting data on my production site.
$demoUser = App\User::on('demo')->create([
//your attributes
]);
Here is an example how you can achieve an Eloquent operation on another connection. The on method returns a Illuminate\Database\Eloquent\Builder instance, btw you can go on and do whatever you want.
I have three different apps for which i want to use the same login and profile. Which means if a user updates his profile information or changes his password that has to be updated in all the apps.
Currently im using a single database for all the three apps, but not sure if this is the right way. I checked few sso solutions, but not sure how to make profile table same for all the three apps.
The reason i want profiles table same for all the three apps is because the apps belong to the same industry(healthcare). If a doctor updates his information on one app, that has to be updated in all the three apps so that his information stays same on all the apps.
I'm currently using laravel 5.6 as the backend api and vuejs as the frontend with JWT login
I am late, but thought would help people looking for answers.
1- Using Different API/Service for authentication
As mentioned in the comments it is a good way to create a separate service for authentication. Could create an OAuth server for that purpose.
2 - Using same Database
It can be done is using similar APP_KEY for three applications. It is generally not a recommended way to use same app key for multiple apps, but in this case as three apps works as one and uses same database dont see a much problem with that.
To do so copy the app key from the main application's .env file to other 2 applications .env files. This is because app key is used in the process of encrypting the password when registering the user and logging in. So, it should be similar in all apps for the hashes to match. This way same database and same users table could be used.
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.
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.