Proposal for a slimmer Seafile Client for Shibboleth

Hi everyone,

I had an idea for an improvement of the Seafile Client when authenticating with a Shibboleth enabled Seafile server.

The basic idea is to use the capabilities of the Operating System to handle URLs to registered application like the user’s default web browser and have it interact with the Seafile Desktop client via specific URLs like this:

  1. When requiring login via Shibboleth, after determining the Server address, the Seafile client leverages the operating system functionality for opening a web browser at a specific URL (e.g. https://<seafile>/accounts/clientlogin)
  2. The user authenticates himself normally as he would when he accesses Seahub normally
  3. After successful authentication, the user isn’t redirected to his Seahub home page, but to a special URL (which contains the Client token) for which the Seafile Desktop client is registered as a protocol handler which (e.g. seaf://login?token=<client-token>) that again leverages the operating system URL opening capabilities.

My idea comes from how the Telegram Instant Messaging Desktop Client ( https://desktop.telegram.org/, source code: https://github.com/telegramdesktop/tdesktop, btw also written cross-platform compatible in Qt :wink: ) handles “user profile” or “sticker pack” links that are normal http-URLs but redirect to an URL that is then handed over to the Desktop application (e.g. http://telegram.me/BotFather -> tg://resolve?domain=BotFather or https://telegram.me/addstickers/ClintonVSTrump -> tg://addstickers?set=ClintonVSTrump).

I think this could resolve the need to have two different builds of client packages for use without and with Shibboleth. Also, it would make it possible for the user to use an already existing Shibboleth session within his browser.

What do others think of this idea for an alternative Shibboleth login implementation?
What do the developers think? Does this seem reasonable and a good technical solution?

Best wishes,
Moritz

1 Like

Thanks for this suggestion! I’ll write my thoughts below.

It sounds like a good design overall. On a first glance, the pros and cons I see are:

pros:

  • unified seafile client installer
  • reuse the existing seahub session in the browser

cons:

  • The thing I’m worrying about most is: on some computers (esp. in some enterprise environment) it may not be able to register a custom uri handler ("seafile://") on the computer, e.g. for security reasons. In such case the proposed workflow would not work, and we had to fallback to the current webview.

cc @daniel.pan

1 Like

From our experience with seafile:// protocol used to implement “open in client” feature, the mechanism is not reliable across operating systems.

Another issue is that the user need to learn to login via browser than work with the desktop client. This is not intuitive way to work with. It is more nature to open the client, click a button the client to login and so on for a normal non-tech user. All happen in the client.

Hi Daniel,

Well, I can only say that it seems to work quite well for Telegram (I’ve personally seen it on Windows, macOS and Linux)…

But

that might be true, I will test that when I’m back at my work computer the next week.

I would not say that this is a real issue. Even more: Whether the webview browser window opens from within the Seafile client or whether the native browser opens would be mostly indistinguishable for a non-tech user! (Provided that the process works as smoothly as it does with Telegram :wink: ).
And it’s a real benefit that an existing Seahub session in the browser would be reused.

And there could also be the comparison to Dropbox again: They switch to the browser from within the native client for any sharing functionality and that doesn’t seem to confuse users either ;-).

Regards,
Moritz

We will keep this in mind and check how Telegram implement the protocol handling in a reliable way.

Hey,

because of my own interest, I checked how Telegram does it for the different platforms.
Here’s three links to the respective functions in source - and it can actually be done all without administrative permissions (e.g. Windows only accesses the HKEY_CURRENT_USER registry tree):

I have just tested that on my work windows machine that is confined within our university’s group policies and it worked quite well there, too. (Though there might be more restricted environments, of course.)

Best wishes,
Moritz