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?
[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=HEADAlso 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=HEADI am pretty sure that you would be much faster using the existing framework when implementing special use cases.
Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: [email protected], http://das-netzwerkteam.de
pgp7UNqa26l1G.pgp
Description: Digitale PGP-Signatur
_______________________________________________ x2go-dev mailing list [email protected] https://lists.x2go.org/listinfo/x2go-dev
