No persisted login about teams-for-linux HOT 19 CLOSED

Just tested the amd64 Debian package and it seems that ssoPasswordCommand just does nothing in my case. Even tested like this:

/usr/bin/teams-for-linux --ssoUser "somelogin" --ssoPasswordCommand='touch /tmp/miau' --optInTeamsV2

… and no file is created under /tmp/, but as it's explained above it maybe needs to go through basic auth which is not the case here.

However, I can't reproduce the login problem at all using this version. I'm not being logged out between sessions so far. Suspecting it is because previously used flatpak package (com.github.IsmaelMartinez.teams_for_linux 1.4.37). Could it be the case?

flatpak and snap CAN be a bit more temperamental about session management, so that might well be the case.

from teams-for-linux.

@gebinic You said that you wiped the state and started a fresh instance, it's expected that the MS login page appear.
What about if you log-in once, then restart teams-for-linux ? Are you still redirected to MS login page? or to your internal SSO directly ?

When I am logged in and have restarted teams-for-linux, the MS login page (=our SSO login page) does NOT appear anymore (which was the case at the time of creating this issue!). BUT I still have to log in again after restarting my PC. I don't have this problem in my browser. Incidentally, we do not have a Basic Auth before our SSO.

From my understanding of this project, it dosen't do any filtering of whatever cookies it keeps, so it should keep your cookie set by your company's SSO... Might have something to do with the policy/workflow of your company?

The MS Teams session is much more persistent in my browser, so it's hard to tell if our MS policies are the reason for my problem. I will talk to our administrators.

from teams-for-linux.

Aye, is the current way it works. If you want to persist and not need to log in, you can use certificates (see the config options).

from teams-for-linux.

Unfortunately, my company does not support/allow certificates for MS logins. Our logins are based on OAuth2 + SSO. I expected teams-for-linux to save my SSO cookie and reuse it for further logins.

from teams-for-linux.

Same problem here. OAuth+SSO only so there is no way to use an alternate auth method. No workaround for such cases for now? Pretty sure it worked flawlessly before, but maybe something changed on MS/policy side.

BTW, thanks for teams-for-linux. A remarkable piece of work.

from teams-for-linux.

If we could override :

Somehow, call a subprocess to have our login/password from password manager... or hardcode it in some config file ect...
I'll try something dirty just to see if it could work and will provide a PR if it's ok

from teams-for-linux.

It should be possible to modify the app/login/index.js file/logic to store the session token, however that storing of token information might open possibilities for people to exploit that.

We could just allow overwriting the username/password (we sort of need this for the proxy connections) but that would mean you needing to store those passwords in plain text in your computer, what ain't great.

Unfortunately there isn't much of an option to call the password manager, as there isn't "a way" but just many different password managers.

We could however explore adding a script execution, so people can just do/add whatever they want. That could be a password manager, a plain text username/password or a much more complicated/secure logic.

I will have a think but do bring ideas.

from teams-for-linux.

I've tried this : #1268
Works like a charm for me. I didn't do any error checking of any sort tho, it's just a fast draft to see if it would work (as I'm discovering the codebase also)

It should be possible to modify the app/login/index.js file/logic to store the session token, however that storing of token information might open possibilities for people to exploit that.

I'm not sure about the technicalities, but for me, the session token is kept without code change, but it's just that my company invalidate session tokens every day to force a full connection, and it uses, as described in the issue, an SSO that fallback to a basic_auth http challenge.

On master/develop, it will prompt a little white windows with "Login/Password" fields, on my branch, those are auto-filled with the new two config keys.

Now, writing this, i'm unsure if it was the issue that OP was describing tbh.. but here we are.

from teams-for-linux.

well, that was fast. Thanks for contributing! I left a couple of wee notes but if you manage to make those changes we can get that released today. Thanks again!

from teams-for-linux.

I think it will work as the login logic is fairly simple. It tries it once and if it fails, it restarts the app.

The only problem might be if someone puts the wrong script, that could create a continuously restarting app, but we can't really control what people put on that script.

from teams-for-linux.

Pre-release in https://github.com/IsmaelMartinez/teams-for-linux/releases/tag/v1.4.40 . That should provide a way around this issue. Please can everyone test it? Thanks!

from teams-for-linux.

I've installed the AMD64 deb package for v1.4.40 and configured in my $Home/.config/teams-for-linux/config.json the two new properties ssoUser and ssoPasswordCommand. After wiping out the old teams-for-linux state and starting an "fresh" instance, the MS login page still appears. I saw in the devtools console two errors:

[85922:0524/160737.826145:ERROR:CONSOLE(1)] "Request Autofill.enable failed. {"code":-32601,"message":"'Autofill.enable' wasn't found"}", source: devtools://devtools/bundled/core/protocol_client/protocol_client.js (1)

[85922:0524/160738.329087:ERROR:CONSOLE(1)] "Request Autofill.enable failed. {"code":-32601,"message":"'Autofill.enable' wasn't found"}", source: devtools://devtools/bundled/core/protocol_client/protocol_client.js (1)

from teams-for-linux.

aye, that will only work if you go via basic auth, but some companies will never allow you to do that. There might be a way using a proxy or simulating a proxy. @lecler-i , do you have any inside on how did you manage to get the login window popping up?

from teams-for-linux.

At my company, I'm redirected to Microsoft login, where I put my email, then it redirects to our internal SSO, that uses basic-auth if i'm in the lan, otherwise it uses normal microsoft login.

That's how my PR fixed the issue for me.
But I can say that my cookie is persisted, and thus the second time I launch the teams-for-linux, I don't have the microsoft login page, but i'm directly redirected to my company SSO (and therefore, the basic_auth)

@gebinic You said that you wiped the state and started a fresh instance, it's expected that the MS login page appear.
What about if you log-in once, then restart teams-for-linux ? Are you still redirected to MS login page? or to your internal SSO directly ?

From my understanding of this project, it dosen't do any filtering of whatever cookies it keeps, so it should keep your cookie set by your company's SSO... Might have something to do with the policy/workflow of your company?

But yea sorry I kind of hijacked the thread about the PR I've done, as :

• it doesn't fix possible issues with cookies in anyway
• it provides the "auto-login" only for http basic_auth challenges

from teams-for-linux.

it is strange as the cookie works fine for me. I need to clean the cache every single time if I want to log out. I wonder if this is a company policy that doesn't allow cookies. Can you check with your cookie monster network admin?

from teams-for-linux.

Just tested the amd64 Debian package and it seems that ssoPasswordCommand just does nothing in my case. Even tested like this:

/usr/bin/teams-for-linux --ssoUser "somelogin" --ssoPasswordCommand='touch /tmp/miau' --optInTeamsV2

… and no file is created under /tmp/, but as it's explained above it maybe needs to go through basic auth which is not the case here.

However, I can't reproduce the login problem at all using this version. I'm not being logged out between sessions so far. Suspecting it is because previously used flatpak package (com.github.IsmaelMartinez.teams_for_linux 1.4.37). Could it be the case?

from teams-for-linux.

Alternatively we can look into using those sso parameters but execute some javascript... Really dirty but we can those to execute the following commands:

• document.getElementsByName('loginfmt')[0].value = '[email protected]'
• document.getElementById('idSIButton9').click()
• document.getElementsByName('passwd')[0].value = 'thisIsNotMyPassword'
• document.getElementById('idSIButton9').click()
  Maybe adding some logic to only try to put the passwd if is a password type (so not to start sticking your password in plan text!) but this is starting to be quite the hack.

from teams-for-linux.

fyi, I renamed the ssoUser and ssoPasswordCommand to include BasicAuth into their names in release 1.5.0 .

They are now called ssoBasicAuthUser and ssoBasicAuthPasswordCommand

from teams-for-linux.

Closing this as it is duplicated with #1045 Both do seem to be the same and dividing into 2 issues only confuses me 😄

from teams-for-linux.