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.
Related
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.
After creating authentication system for user using Laravel 5* I am wondering where Laravel store user session?
In other words Laravel store user session in a cookie(client side) or server side?
And if in cookie so it hash that session right? and this is not secured right?
Laravel stores it on server side. You can choose where to store it: files, DB, Redis etc.
Laravel ships with a variety of session backends that are accessed through an expressive, unified API. Support for popular backends such as Memcached, Redis, and databases is included out of the box.
You may learn more about sessions here.
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.
My server needs to log-in to another server (for accessing payment API). Result of successful log-in operation is a session token that is valid for 25 minutes.
Where can I store this session token so that it is available across multiple requests and multiple users? (i.e. user session is not an acceptable solution).
I need some sort of an application state or cache storage.
Just to demonstrate the problem - a file could be used to store this value, but I don't want to deal with concurrency, and security implications this solution comes with. I would prefer an in-memory solution.
You could use either the core JSession or JCache framework objects.
http://docs.joomla.org/JFactory/getSession
http://docs.joomla.org/Using_caching_to_speed_up_your_code
http://docs.joomla.org/Cache
We have a Java Spring application with lot's of contacts inside a database. Now we'd like to provide these contacts via CardDAV in order to access them via external devices.
As far as I understood CardDAV, it uses the 'well-known' protocol. Which means, it'll look up http://mydomain.com/.well-known/carddav
This might be a problem, because we have a Tomcat Server running, and multiple applications running on it and each of them should provide a CardDAV server. This means, our URLs look like:
http://mydomain.com/appOne/
http://mydomain.com/appTwo/
http://mydomain.com/appThree/
Each of those applications has a completely different set of users and data. Though each of those CardDAV repositories has to lookup its own data source and has to use its own authentication mechanism.
The question is of course: How can I get multiple different CardDAV servers with a single domain?
Btw: Is there any REAL information about CardDAV (not just WebDAV or is it all the same?!)?
For example I couldn't find anything about multiple repositories / access right restrictions. Maybe I want to have a single CardDAV server with multiple different Users, where each user has an own address book and there are some common address books.
The well-known url is used for clients to automatically discover the root of the carddav server, when a user just types in a domainname. You can only redirect to 1 server per domain, but you could setup multiple domains to redirect to multiple carddav servers.
If you can't use multiple sub-domains, you simply cannot use well-known. Instead, you will have to ask users to fill in a full url to their principal to setup their acccounts.
As to your question if there's 'real' information. rfc6352 is the official documentation. It's definitely a lot more than just WebDAV.
Effectively, iOS only supports well-known. If an iOS device cant connect via well-known it will allow the user to enter a complete principal address, BUT thats only AFTER displaying an error message to the user, at which point most users will give up.
However, the redirect occurs after authentication, so as long as you're able to authenticate at the root (eg with a username scheme that incorporates the sub-site, like 'appOne:brad') then you should be able to do it. Alternatively, as mentioned above, just use subdomains.