[X2Go-Dev] [X2Go-Commits] [x2goclient] 01/01: Client now sends "login" parameter to the broker when executing task "selectsession". Before client just sent a username on the broker and it was imposiible to find out user name on X2Go server, which is not always the same as broker username. This won't break a compatibility with previous broker as they just will ignore this parameter.

[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?

[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
-- 

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: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20181221/9b607db2/attachment-0001.sig>