I’ve few questions and comment about Seafile client authentication (v6.0+).
First, about Shibboleth client part, when it open the authentication web page It would be nice if an address bar was displayed. This for security prevention reasons… User can check the adress to which it is redirected, eventually check the certificate… to avoid eventual phishing or anything else.
In Shibboleth client, it would be nice to grow up size or visibility of the “Shibboleth” log in button. And another thing about the server adress, when I click on Shibboleth button it would be very great if the next windows was pre-filled by the server address on the precedent window, and use by the client preconfiguration file (seafile.ini / .seafilerc)
I would like to know how authentication token is set and keep in the seafile client… Is there a documentation about that ? A specific client documentation ?
In Seafile client I’m not log out when I quit the application… I think it would be great to log me out of all my potential servers when I quit, like if I’ve click on “Disconnect” button for each of them.
Other users reported such requests before. We will improve it in the future.
Supporting preconfiguration file is a good suggestion.
After login, the server returns the token just as you get a token via web API. The token is saved in local database.
For syncing client, the logout is not quite useful because the files synced are stored in local folder and can be accessed without Seafile client running.
Other users reported such requests before. We will improve it in the future.
Ok good, you know when ? (approximatively…)
Supporting preconfiguration file is a good suggestion.
With preconfiguration as I can see/test, the preconfiguration address is not always take to pre-filled the server address (the field when I click on shibboleth button I mean) (on Windows for example that doesn’t work) and that doesn’t avoid the user to fill in user/password field for nothing… Maybe it would be better/easier to seperate the two authentication methods before, with “Add an account” + “Add a Shibboleth account” or something like that ?
After login, the server returns the token just as you get a token via web API. The token is saved in local database.
How long the token is saved ? Is it deleted at one point ? When we log out ?
For syncing client, the logout is not quite useful because the files synced are stored in local folder and can be accessed without Seafile client running.
(I guess that is matching with the previous question)
I think it’s not a really a good answer, first because it seems to me that files that are doesn’t sync are visible and previewable by Seafile Client, and can be download, share; etc. too… am I wrong ?
So, if the client is doesn’t logout correctly, we can imagine that someone with access to the machine can get information that are not reachable in a local folder.
Another way of seeing things : what the object of keep session log in when user decide to close the application ?
For me it’s like save password in a browser… If you hope that nobody will never have access to your browser so… ok no problem. But how can you be sure ? and if it the case he will have access to everything ?.. And the problem here is that when we quit, we are not warned that the session isn’t “closed”.
I know that this problem is a “detail”, but maybe a checkbox : “keep session active after logout” (or something like that in parameters) can be add ? Allowing users or admins -with preconfiguration- to decide between “simple closing” without logout, and “full closing” with logout from all servers connected.
Having this as a configurable option seems like a good idea to me.
But for your other points: It is quite normal for an application like the Seafile client to cache session credentials (a.k.a. being logged in) for as long as the user explicitly deauthenticates. I absolutely do not want to re-login to my Seafile client on my machine when I restart it!
Just think of the usual comparison to Dropbox: Their desktop client doesn’t require you to login more than once either.
I don’t quite understand your risk assessment: Do you fear that an other user on your machine uses your session token to access the Seafile server to see libraries that you haven’t synced to your machine?
I agree, some people don’t want to be log out when they quit the application, but some other people think that when they quit they are disconnected. So that’s why I think it’s important that can be configurable. For me if you do “the action of quit”, your session should be closed and you should be disconnected.
I don’t know if it’s a risk in real situation but theoretically keep a session open “eternally” without any knowledge of it doesn’t seem very secure I guess.
We will look at the issue. But separating the two authentication methods before is not the way we will go. Because we don’t like to change the original workflow which is already used by many users.
