Hi Mike Am 21.12.18 um 07:49 schrieb Mike Gabriel: > Hi Alex, > > On Fr 14 Dez 2018 12:24:39 CET, Oleksandr Shneyder wrote: > >> Hi Mike, >> >> My customers have different brokers. Some of them giving back sessions, >> depending on broker login, other on x2go server login. One of the >> examples: >> >> I'm logged on the broker as "Alex", you logged on the broker as "Mike". >> Both of us logged on the one of the servers in server pool "Lab-1" as >> user "labuser". We suspending our sessions. When we are logging to >> broker next time, I'll get my session and you yours. > > I'm ok with the final login result of this model. The X2Go Session > Broker can now handle this, I think. > > However, I am concerned about the session cards in X2Go Client. When I > log into the broker, X2Go Client's session cards notify me about running > or suspended sessions. At this time, the only know username is the > broker user. Of course, I can put the X2Go Server user already into the > session profile. > > How do you handle the display of "running session" / "suspended session" > [1] on the session profile cards?
same here. Different use cases - different solutions. In some cases username on server is saved in session file. In other cases x2go broker get the user sessions from broker database. This details I'm usually discussing with customer and we deciding together what is the best solution. > [1] > https://code.x2go.org/gitweb?p=x2goclient.git;a=blob;f=src/sessionbutton.cpp;h=0bbbdc98e65fb720cd8cb5610c5dbb76aac4c8a6;hb=HEAD#l327 > > >> In the server pool >> "Lab-2", however, I want that broker user "Alex" could resume all >> sessions started by X2Go user "labuser". And maybe user "admin" could >> resume all sessions, doesn't matter who started them. And so on. >> Different customers have different use cases. I'm creating the brokers >> for the customers to perfectly fit into their infrastructure. All >> brokers are different. It's like a tailor suite. This is why I never >> supported a "legacy" broker. "Legacy" broker means that customers >> supposed to adapt their infrastructure to our solution. And it's exactly >> the opposite of what I wanted to achieve with X2Go broker. > > Please note that you could add such use cases easily as custom broker > backends in X2Go Session Broker. > > E.g. I wrote a simple zeroconf broker backend as example: > https://code.x2go.org/gitweb?p=x2gobroker.git;a=blob;f=x2gobroker/brokers/zeroconf_broker.py;h=656f0dc34646ec4ce9fe000b860b59d601d77369;hb=HEAD > > > Also authentication backends (called mechanisms) can be customized, so > can nameservice backends (mechanisms): > https://code.x2go.org/gitweb?p=x2gobroker.git;a=tree;f=x2gobroker/authmechs;h=f3a450f7d18249a836c9142cd3a7f1590fe1f6cb;hb=HEAD > > https://code.x2go.org/gitweb?p=x2gobroker.git;a=tree;f=x2gobroker/nameservices;h=efb8453d6b6380e5f8ab8074c924938426084ac9;hb=HEAD > > > I am pretty sure that you would be much faster using the existing > framework when implementing special use cases. > > Greets, > Mike -- ----------------------------------------------------------- Oleksandr Shneyder | Email: o.shney...@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461 Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973 -----------------------------------------------------------
signature.asc
Description: OpenPGP digital signature
_______________________________________________ x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
