i'm trying to achieve this, different installations of laravel framework on different servers working with each other and sharing resources with the main application(super application) as in the Diagram above.
The super application sits on the main server and houses the user management module which determines who is currently logged into the system.
and if logged in, you can then load other modules which is another laravel 5 setup that sits on a different server.
these applications work only if a user is logged into the main application. and the Auth->user() object on the Super application is sent to the corresponding applications (A1 and A2) for data entry.
my initial approach was to implement HMVC using laravel 5, but HMVC implies that only one laravel setup be used, which means using only one server. But when you have different applications running seperately on different servers and try to bind it with authentication from a primary application from the main server, i had no idea how possible this is, but i believe it can be done.
Please how do i achieve this, that is how my boss wants it, and insists it be this way.
It's a strange setup, but I have two solutions in mind:
1) If your applications can share the same domain you could use a shared cookie. For instance, let's say that your applications are configured as follows:
SA example.org (which points at server 1)
A1 a1.example.org (which points at server 2)
A2 a2.example.org (which points at server 3)
From SA you can save an identification cookie for your sub applications (and each Laravel installation can access it).
2) If you can't share the same domain you can login on SA, then redirect to your sub applications using some POST data. A1 or A2 will be able to gather the identification parameter from the request and save it in the session / cookie to remember you.
Finally, having your identification code, you could write an API to retrieve the user's data.
Related
I want to ask about authentication in Laravel.
So the case is, I have 2 apps that have correlation, among others are,
1 application is used (we call it, system A web application) for systems that process databases, such as creating blogs, editing, editing, and approving articles made by creators, and of course having login authentication to the application to process it. (https://uat-system.marsiajar.com) <- you can access it by using my username and password, email: sariayu.mahgdalena#gmail.com, and the password is h67v3km2.
1 is used again (we'll call it web application B), to preview everything generated by the system application, on this web, the system database is only used to update blogs, such as adding/editing the number of views to the blog. (https://marsiajar.com)
The correlation is, these 2 applications use 1 database that is on the server.
I want to know
1. How do we know or show, when a user logs in to system A's web application, the user's name will appear in B's web application?
I attached screenshots and an interface view of system A's web application,
https://ibb.co/nbW4d5c
and I attach my env's config to this,
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=marsiajarroot_uat-landingpage
DB_USERNAME=marsiajarroot_uat
DB_PASSWORD='*******'
this env, I used in system A's web application and in application B,
Please, does anyone, know about this?
Can we share about this?
Thank you very much for sharing ^_^
This was on previous case before. The truth is you cannot share the cookies or session. It might be but its not the best practice. One thing i do is to use Database SESSION_DRIVER and put some variable on it (forgot the name) but as long as it is still in the same domain, i believe this thing would works.
I have 2 applications : the first one is written with ruby (It's redmine) and the second one is a Spring boot app and both are hosted on the same tomcat server.
How can i do that?
Sharing sessions is not allowed. By (servlet spec) definition, a session belongs to a single web application.
Reference: Servlet Spec 4.0, section 7.3:
HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container.
There are ways you can probably work-around this limitation by setting-up shared caches, etc. but it will always be brittle and potentially dangerous from a security or resource-usage perspective.
User database or user data file(nosql) with use of a unique-user-auth-token, accessible by two apps (or 3, 4, 5 ...)
Global concept :
App request connection :
is exist "old auth token" in app storage ?
yes -> app send old and request new or same if not expired
no -> continue
is exist valid auth token on server ?
yes (an app is already connected) -> send validated auth token to app
no -> set new auth token and send to app, new AT is ready for other app
server store what app request connection and is connected
apps are now able to exchange datas via the server.
Sharing Web applications is, at a minimum, Bad Practice (TM): Web Applications are completely separated by design. If both applications easily could reach into each other's session: Imagine what would happen if one would overwrite values that have been set by the other, and both applications expecting different data under the same key name.
If you only need single-sign-on, there's a SingleSignOnValve available that will make sure you'll only need to sign in once (provided that you authenticate through the container, e.g. a Tomcat Realm). Check server.xml for the commented-out-default-value, or the documentation for more information on authentication and the valve.
You might work around it by implementing the UI in both modules and refer back to a common business logic, but this is a level of architectural change too broad to fit into this answer.
I have 3 laravel Applications with 3 databases.
Application 1 is the Login for authentication (Registrations and Login) and is only connected to the users Database .
Application 2 allows user to perform some basic operations and is connected both to user and App2 Databases
Application 3 allows users to perform some other operations different from application 2 and is connected to users and App3 Databases
Now my problem is to allow a user looggin once through Any of the applications and is automatically logged in to other application
More like having a single google account that works in all apps.
Application 1 will be access through the main URL
www.kokoka.com
while others will be access through
health.kokoka.com
school.kokoka.com
I have tried
https://github.com/awnali/SSO-laravel-5
I have also changed the Domain in session.php
'domain'=>'.domain.dev'
all to no avail
You need to set the session file to database and everything related to sessions should be identical. Basically the session.php file should be the same between both, they should have a common database, and the key and cipher type should be identical.
If they have the same domain name (ex: server1.mydomain.com, server2.mydomain.com) but different hostnames/subdomain names, then the cookies should still work fine as long as you set the domain correctly (ex .mydomain.com). If they are on the same server, you can still use a common key-value system. If they are on separate servers, you either need a common storage location (like S3) or a replication enabled key-value system like Redis or Memcached. You could also use MySQL if you need to replicate other data types, but it's very heavy for just key-value pairs.
If they have completely different domains, then cookies will not work. In that instance, you would need to reference cross-site session ids through GET query strings, and perform session migrations in the back-end using either common or replicated systems, or via some secure API. This is a very difficult system to setup and only works if you are moving between the domains using links embedded in the sites. Bookmarks or manual address input will loose session data.
Another way to acomplish what you need is to use the new funcionality of laravel passport.
Laravel already makes it easy to perform authentication via traditional login forms, but what about APIs? APIs typically use tokens to authenticate users and do not maintain session state between requests. Laravel makes API authentication a breeze using Laravel Passport, which provides a full OAuth2 server implementation for your Laravel application in a matter of minutes. Passport is built on top of the League OAuth2 server that is maintained by Alex Bilbie.
This will let you share data across multiple domains through an API so you can share the session and user information. This is the way most people prefer.
tl;dr: trying to use one app's user credentials on different other apps. Tried a solution, but I have hit a roadblock and looking for better ideas.
--
Say I have 3 different laravel 5.4 installation, and let's call them "App1", "App2", and "App3". Those 3 apps have completely different functions, and they could be used by the same users.
At the moment, the users are using App1, and their login credentials and information is resting in App1's database.
App2 is located on the same private network as app one, so when I wanted to give the users of App1 the ability to login App2 with their existing credentials, I went this way:
Created a database connection in App2 that points to App1's database, using the private IP address of App1;
Used this new connection on the User model of App2 and bam, it worked.
But now I want to offer the same possibility with App3, but it's not located within the same network and I'm starting to see the shortcomings of my actual solution.
I could of course open the database connection of App1 to App3 specific IP address and keep the current setup, but I feel it's getting messy, and I guess it could be a security risk (I'm not knowledgable enough in this area to really know).
Then I'm thinking : API? Maybe Passport? Is this actually a road I should (and could) consider? If so, what would be an easy way to achieve it?
You might wanna look into a SAML solution that would allow you to share credentials across multiple apps and domains.
You can either use this Laravel package or use vanilla php-saml
I´ve started using spring session successfully with one nginx, two tomcats and one redis server to implement clustered sessions and some questions have arisen.
First of all, I mean two completely applications when I talk about different applications, I don´t talk about two instances of the same application.
May I use two or more different spring-session applications to store sessions with only one redis server in production?
These applications can run in different tomcats instances?
How Spring session avoid session id conflict between different applications with one redis server?
Is it necessary to append suffix or prefix id to avoid this problem?
Spring Session does not natively support for scoping sessions at this time. See gh-166 for details on tracking this.
Spring Session generates a secure random id with high level of entropy for session id's so there is extremely low probability that you will get collisions.
This means that you can use the same Redis instance for multiple applications using Spring Session so long as you are ok with the following statement:
A malicious user can use Application A's session id with Application B. Why is this important? Consider the following scenario:
Application A is a public application which any user can create an account for.
Application B is a private application which only users who are invited can sign up.
The malicious user creates an account and authenticates with Application A
The user copies their session id for Application A. They navigate to Application B and paste the session id into their cookies for Application B and are now authenticated.
This might not be a problem for you. For example, good security practice would ensure that the user is properly authorized by looking for an ADMIN role in Application B. Application A would not populate that role, so while the user is authenticated with Application B they are not authorized to use it.