I have just came across a usecase in which same user (or user with same token) have to connect the session twice, what actually I found everything is working fine. But still curious to know.
In tokbox, if a user joins with two different tabs that is same token what will be happened at server end of tokbox and will it be consider two different viewer?
This will be two connections within the session - so different "viewers", yes. Each connection will be publishing and subscribing-to its own streams, so could be doing different things. This is unusual use case (which typically causes audio feedback etc.) so make sure this is what you really want in your design.
Related
So I have decided to rewrite an application I have been writing in Node.js to Elixir because of all the extra complexity working with Node that Elixir comes with out of the box.
My issue was something I didn't have quite right in Node and is becoming just as complex in Elixir and I am not entirely sure how to go about approaching it.
I am trying to recreate a lot of how Discord does permissions. I am essentially building a CRM system, with different roles like "Sales Manager", "Sales", "Customer Service Rep" etc... But they all are able to do different things based on their "role".
Some things I need to do is be able to update a permission on the fly for a person or role. Maybe the "Sales Manager" role can't look at company financial data like an "Accountant" but we need to give that specific person access for a few days. Or I have a "Customer Service Rep" and we give that entire role the ability to add things to a calendar. I also would like to have the ability to kill sessions.
So there are a few ways I've seen said around Elixir forums, like:
Using Guardian, I really want to like tokens and think not having to hit the database every time sounds wonderful, but I don't think it's practical for this. Unless there is a good solution to updating tokens on the fly which I haven't found.
Giving each person their own process and just kill and start the process on changes with new changes. This seems pretty neat, but I'd rather not kill processes unless there is an actual error, I think this solution will come with big problems, like tracing problems. Although I am not familiar enough to know if this might actually cause problems, or if this is a bad solution for other reasons.
Use Guardian with Guardian_DB, which then defeats the purpose of using tokens, but at least I'd have a trackable session. My only problem with this is I do plan on using a load-balancer so that if a socket connection dies I can reconnect it to the same server and I am not sure there is a way to do that with tokens or if the socket itself has a session attached to it. This is not really that big of an issue though and is pretty close to what I had with Node.js.
Use Redis which I'd like to stay away from, and then update session data in Redis based on user_id when updates occur and hit Redis on every request to see if the user has permissions. I plan to put this across multiple servers eventually which means ETS is not viable unless I can load-balance socket connections like I could in Node.js.
So I guess my questions are,
Can I attach sessions to sockets? Is this a bad idea?
Should I still use a token, and just use Redis to check the token on every request?
Is a token still a better choice than a session?
Is there a much better/easier solution that I have not even mentioned?
I'm sorry this was pretty drawn out and long, I've never had to do something as permission bound as this project professionally and am pretty new to Elixir.
Phoenix channels are stateful. You can put data in the assigns field and it stays there for the duration of the connection. That is where you normally put your user_id after authenticating the user on join.
I also use the channels assigns to store client state that I need on the server.
WRT to the role to permissions question, I'm doing exactly this. What I do is load the load the role permissions from the database on startup and build an ETS store with them. You can do the same with a Task or a GenServer. If the permissions change for a given role, i update the database and the ETS table.
My user model supports a list of roles for each user.
When in need to validate the permissions for a given user, I call the Permission model api like Permission.has_permission?("create-room", user, scope). I have two level of permissions, global and per room. That is what the scope is used for.
If possible i want to use my computer to emulate multiple clients (like TPC-W) on a web server, i tried to use Htmlunit however when i created two WebClient() they had the same login session (when one logged in the other was logged in as well in a stateful bean, it causes the second one to crash because the login form disappears after the logging in).
The reason i'm not using TPC is because i want to benchmark on my own web pages. I'd like to know if it is possible to use TPC to emulate my own pages or a library/trick that can do the job.
It seems the answer to my question was written in the following question.
prevent Shared session with multiple browser windows
The answer is: multiple logins in a single session. Thanks goes to user191966 for the answer.
I've got several sites that I'd basically like to have the same user system for.
One of the sites runs XenForo, the others all run Codeigniter, or systems built on Codeigniter (e.g PyroCMS).
I need to somehow be able to let a user login on any of the sites with the same username/password combination, in addition to be able to register.
I know there are a number of ways of going about this, such as an OpenID server, however I'm not 100% sure which is best for my situation given that I'm using two systems that arent exactly going to play nice together.
I'm not too bothered about having it autologin across all sites at once, but just dont want people to have to use multiple different credentials.
Would I be right in thinking something along the lines of a central OpenID server, with openid authentication on the 'slave' sites would be my best option?
I'd ideally like to use the XenForo user table as the 'master' user table in this situation.
Any input or suggestions would be greatly appreciated.
I wrote one here a while ago, I've not updated it in a while though should still be good :
http://www.jeremyhutchings.com/2010/12/xenforo-and-codeigniter-intergration.html
Let say I have a simple architecture where sessions would be shared through a database, with multiple frontends (say F1 and F2) speaking to the same backend.
My issue is the case where both frontends would receive a request corresponding to a same session: a naive implementation would cause session to overwrite each other (I looked at django which seems to fall into that case). I could try to design the backend such as it garantees that no more than one frontend can deal with a given session, but this seems hard to do correctly, especially if I want to handle frontend failures.
I can't help but thinking that the case is pathologic in the first place (there should not be more than one request for a given session at any time), and is not worths being dealt for, but I have not much experience in web development, so maybe I am missing something. How does one usually deal with this case ?
Possible solutions that I would like to avoid:
Sticky session: that's the solution I currently use, and is difficult to support once you have several load balancers, and more significantly goes against the spirit of load balancing in the first place.
Putting data in cookie: for technical reasons outside my control, I cannot use cookie.
One common solution is known as session persistence. Whatever routes your request to the f1 or f2 ensures that as long as a session is active, the client with that session only goes to one frontend.
It is a common feature in almost all loadbalancers. For example, nginx has the ip_hash http://wiki.nginx.org/NginxHttpUpstreamModule
I have a very basic knowledge of the web programming, and I couldn't figure out the answer to this question.
Typically, a cookie is used to identify a session in web applications. However, as far as I know, multiple browser windows share cookies. In that case, how does web applications distinguish between the tabs?
Edit: I guess all the answers are saying the same thing - there is no standard way to handle this. Ok. Thanks for resolving my uncertainty guys.
However, as far as I know, multiple browser windows share cookies. In that case, how does web applications distinguish between the tabs?
It cannot distinguish at all. Hence comes the challenge for web developers - make their application robust to prevent data destruction or unauthorized operations when access is performed from some other "outdated" tab.
They don't. The application does not know that you have two tabs open. If you are tracking sessions then it can know that you have two sessions open.
What are you trying to accomplish?
They don't. You have one cookie per different browser (ff/ie/ google chrome).
You'll have to distinguish the tabs client-side (ie Javascript).