Okay so I am building a website in laravel it consists of users which has one to many relationship with orders. What I want to know is if its possible to implement a messaging system with web socket for each particular order. So essentially user to user, with the exception of admin being able to chat via admin panel. Any advice on this matter will be great.
Related
My question title may not appropriate as I am not so aware of how to call it. I will appreciate it if anyone can edit to fits the query.
I am planning to build a web application where users will subscribe. For instance, CRM or Project management application. I want to have a separate instance and database with a custom domain for enterprise subscribers, and I may have a common database or instance for non-enterprise subscribers. The subscription will be handled through a marketing website, where all subscribers will checkout and have their own account.
Marketing website to subscribe
Application instance / website/ database / etc
Once the subscription period is over and it is not renewed, they will lose access. If they do not renew/reactivate for x time, the instance will destroy itself.
I am quite confident with PHP and MySQL, have some knowledge of AWS and Digital Ocean. I am planning to use Laravel for serverside. However, I am open to other languages as well, such as python.`
Can anyone help me to learn the best approach for the system I want to
make. Pros and Cons and things to be considered? Also, approach to make a mobile application for the subscriber where they can access their own instance.
How to make 2 separate back end apps served as one site, each handling different requests, ideally 1 embedded into the other, sharing a session once user is logged in?
Currently there is one bespoke website/CMS application (app 1) not unlike a blog with a login form and signup. It uses oauth internally to connect to an API for the database on a seperate app. Blog posts are public on the website, customers login to the main site and can upload posts and see their editorial progress, receive feedback and more before the post can be made live, and Admin use a CMS to access what is submitted by customers and manage the posts including proxying in to users as needed to make changes.
I now have another web application (app 2) to replace some of the functionality in the original CMS. It has its own CMS and frontend, login, and users stored in its database.
I need a way to integrate the two of them so that customers login to app 1 and when they navigate to their post creating/editing they are seamlessly using app 2, no additional login, all using the original apps user auth. Admin can visit both apps CMS, ideally also with a single login.
My first thought was I need another app/service to manage authentication and act as a gateway to the other apps serving pages?
I see a lot about Single Sign On but it seems to relate more to using an external account to access my site "login with Facebook".
What pattern for the infrastructure and code would be applicable in this instance? All apps are built on PHP, hosted on Linux.
Single Sign-On (SSO) is what you want, you're on the right track. Read up on protocols such as SAML or OpenID Connect, pick one that you feel comfortable with and has support in your toolset, implement a small test case and go from there. SAML with PHP has a really nice toolkit: simpleSAMLphp
With SAML, you have an identity provider service that authenticates users via, say, a login form and a backend user database and one or more service providers. Each service provider is an app that enjoys the benefits of SSO. The identity provider could be implemented as a stand-alone app/service or it can be embedded into one of your apps, likely app 1. App 2 will be a service provider. Assuming you'll have implemented all of this correctly, your users will be able to click on a link in app 1 that lands them in app 2 without re-authentication.
I'm writing an app that has both client and admin side and I need roles and sub-accounts (for client side) feature.
I understand that there are many of this question but I'm not sure which way to go as I want the admin side too. What would be the best way to do the admin side? what about setting different user groups (ie group client and group admin) or else?
Any thoughts for Laravel5 package or something?
Thank you
Laravel 5.0 comes with a basic Auth system but doesn't comes with ACL.
ACL can be implemented in so many ways based on user requirements it would not make sense to ship an ACL with Laravel core.
There are many ACL on packagist.
Personally the role based access controlled (RBAC) I've used in past project is:
https://github.com/Zizaco/entrust
I am using Yii framework, and have one Data Base for my web application,
and i have one data base for Mibew messenger (webim chat), so I have two different databases.
I have one log in page for administrator page, and chat messenger have it's own log in page,
what I want to do is when i log in with my administrator details (which are in Yii web app database) to be automatically log in Mibew messenger.
I use this messenger inside my application.
Any suggestion how can I fix this problem,
Sorry if my question confused you, I don't know how to ask it correctly :)
Thank you very much,
Cheers.
Only have one database containing the login details, and connect to that database with the other application just for the login details. Or build a login API for one of the applications to use.
I want my app to be able to edit all events for which user is admin. It appears that the app can only update events that were created by the app. I've tested this a few different ways and it always comes the same. It returns error 200, permissions error.
Is this by design or is it a bug? Is there anyway to grant permission to the app to allow updating events not created by the app?
Events that were initially created by the app can be updated by the app.
This appears to be by design. The app must be designated as admin of the event. It can only be assigned as admin if the app creates the event. There is no way to find all admins of an event, either.