I want to create two portals on same server and diferent subdomain:
app1.domain.com
app2.domain.com
I want to separate in two different laravel projects, when it is authenticated in one of the portals in the other portal should be authenticated.
How can i do that? Any suggestions would be very helpful
I think you are looking for SSO
For Laravel in my quick search found some Packages
jasny/sso is one of them, explained as :
How it works
When using SSO, when can distinguish 3 parties:
Client - This is the browser of the visitor
Broker - The website which is visited
Server - The place that holds the user info and credentials
The broker has an id and a secret. These are know to both the broker and server.
When the client visits the broker, it creates a random token, which is stored in a cookie. The broker will then send the client to the server, passing along the broker's id and token. The server creates a hash using the broker id, broker secret and the token. This hash is used to create a link to the users session. When the link is created the server redirects the client back to the broker.
The broker can create the same link hash using the token (from the cookie), the broker id and the broker secret. When doing requests, it passes that has as session id.
The server will notice that the session id is a link and use the linked session. As such, the broker and client are using the same session. When another broker joins in, it will also use the same session.
HTH!
Related
I'm developing Spring Boot Web App.
The problem I have and I couldn't find any solution is: What the proper way to determine what DB user established a handshake by STOMP in DefaultHandshakeHandler.
I have one microservice that for working with users, it has own DB and store users in some table. I want make a chat microservice and I'm not sure what is the proper way to determine exact user that connected. I don't want to connect chat microservice to the same DB.
So overall my question is What is the proper way to determine in any momment what DB user is represented by generated STOMP handshake handler or what is the proper way to generate those id (overriding default handshake handler for example) and connect them to users from DB.
I don't quite understand how this happens. For example:
Some user visits some site (user sends a request to server). The server sends a response along with a unique session_id.
The user passes authorization.
The user is logged into their account. There user sends different requests to the server.
How does the server understand that all requests are from the same client? Relatively speaking, does the server note in some kind of temporary storage (it's valid only for the duration of the session) that some user_id must be opened with some session_id? And does the server use ip address to identify user?
You seem to referring to a web service.
The login process either sets an HTTP cookie containing the session_id or that ID is passed along as a URL parameter.
Since you've tagged your question with ip, you can't use the client IP address for managing the session due to the ubiquity of NAT.
Roughly speaking a HTTP SESSION is a kind of secret that the server sends to the client (ex browser) after user's credentials is checked. This secret is passed trough all subsequents HTTP requests and will identify the user. This is important because HTTP are stateless - source.
Now I have a scenario where there is a communication between a machine and a MQTT broker inside the AWS-IoT core. The machine displays some screens. The first screen is the login and password.
The idea here is that after the first screen, IF the credentials are validated, the server should generate a "session" and we should send this "session" across the screen pages. The machine should send this "SESSION" in all subsequent messages and the server must to validate this string before any action. This is a request created by an electrical engineering team.
Me, in the software development side it seems that make no sense since all machines to be connected in the AWS IoT-Core broker (MQTT) must to use a certificate - with is the validation already.
Beside of that, the MQTT broker offers the SESSION persistence capabilities. I know that the SESSIONs (QoS 0/1) in the broker side are related to idea of confidence of delivery and reception of a message.
That being said is it possible to use session persistence in MQTT to behavior like a sessions in HTTP in order to identify users across screens in devices? If yes how?
No, HTTP Session concept is not in any way similar to the MQTT session. The only thing held in a MQTT clients session is the list of subscribed topics, a HTTP session can hold arbitrary data.
Also MQTT messages hold NO information about the user or even the client that published the message when it is delivered to the subscriber, the ONLY information present is the message payload and the topic it was published to.
While MQTTv5 adds the option to include more metadata, trying to add the concept of users sessions is like trying to make a square peg fit in round hole.
If you want to implement something as part of the message payload then that is entirely up to you, but it is nothing to do with the transport protocol.
Is it possible to do this way:
WampSharp client app connects to a WampSharp Server, then this server sends message/call client's function?
The client can subscribe to a topic and then you can publish to this topic, specifying in the publish options' eligible property the session id of the client.
For functions this is more tricky - you would need to register the procedure with a unique name which depends on the client's session id and then call it from the server side.
I'm trying to integrate an openFire XMPP server to my current company Spring server but have two major questions I cannot find the answer to -
I'll start with my current architecture first -
1. The xmpp server have a DB-server of it's own seperated from the Spring server DB, This is a dedicated machine to keep the users char history etc
2. The spring server have a DB of it's own where it keeps the user credentials (md5 encrypted) and also client applications data
3. The spring server is dedicated to serve HTTP requests (a dedicated REST server)
All in all I have 2 DB servers once chat server and one Rest server
Now for the questions -
1. Can I forbid registration to the xmpp server (i.e. whitelist the rest server ip and let it be the only one who can create users after a user registers on it)?
2.For security reasons the Rest server switch the session for a logged in user every 2 days the iOS and Android clients deal with session managment locally - How can I use those session with the XMPP server?
To clarify - I want the users to be able use the xmpp server only for chat purposes but only after they logged in to the application itself since the user session may expire the chat client will also have to re-authenticate against the REST server, how can I achieve this?
3. Won't it create an overload on the REST server? (i.e. the Rest server will now have to handle client requests and also XMPP server requests)
4. What is the best architecture to achieve this kind of a system (chat server, db server for chat server, rest server, db server for rest server) so that the system can scale horizontally?
I searched google for an article or something related to describe the general architecture but couldn't find nothing relevant, since I'm not "inveneting the wheel" here I would love to hear a good advice or be directed to an article that explains the How-To's
Thanks in advance.
The standard way in XMPP world for user authentication is SASL.
SASL have a very simple model: server sends to client some "challenge" string to client, and client sends "response" string to server, and they repeat this until server decides client send all required data. What data to send is defined in SASL "mechanism". There are number of well-known SASL mechanisms, e.g. SCRAM, and they are provided by most XMPP servers and clients "out of the box".
Your problem is - you already have authentication system and user database and want to reuse it for chat purposes. There are two ways:
Add your custom REST authentication as SASL module to your server. Google say it is already possible to write and add Openfire SASL plugin. Your SASL REST mechanism will do the same things as for browser, but required urls, tokens, etc. will be wrapped as "challenges" and "responses", e.g. server will send REST auth url as "challenge" for client, and client will open url, post credentials, get a token and send them as "response" back to server. Of course you need to add this SASL REST mechanism in client too.
Adopt your XMPP server to use your authentication database directly. In this case you only need to modify Openfire code to link it with your users/passwords tables (maybe there is already an admin tool for this). In this case clients will continue to use standard SASL mechanisms without modification. When this way may be easier than first one, remember your XMPP server should have access to plain-text passwords, which may be insecure.
You questions in order:
Yes, you can disable registration from XMPP client and point users to registration website.
You will see chat sessions in Openfire administration console and able to stop them, also you can write a module for do this by your schedule
If you will write SASL REST mechanism, there will no any difference between requests from chat clients and web clients for your REST backend, they will look the same.
As I described first, you no need separate DB for chat server and you able to setup multiple chat servers connected to your REST backend.