S2S: Reuse session instead of authenticating on every request

[LukasReschke]

Currently server-to-server sharing's authentication mechanism is implemented within

core/apps/files_sharing/lib/connector/publicauth.php

Line 39 in 9df50c7

protected function validateUserPass($username, $password) {

, in this code the password is verified for every single request.

This is a very huge performance drawback as the password is hashed using bcrypt which consumes a lot of CPU power. Instead we should generate a session which can be then reused by the remote ownCloud server instead of re-authenticating on every request.

@icewind1991 FYI

[PVince81]

Setting to 8.1 as this makes server to server sharing very slow, something to look at.

CC @DeepDiver1975 @karlitschek

[PVince81]

So, as discussed on IRC with @LukasReschke we need to catch the cookie and resend it with auth, then just reuse it for further requests.

But currently we use Sabre\Client which relies on curl.
And you mentionned that Guzzle is a nice HTTP client that could do it.

Possibly solutions:

1. Use Guzzle ourselves instead of Sabre\Client
   or
2. Try and make Sabre\Client use Guzzle instead of curl (if possible from the class structure)
   or
3. Find a nice and hacky way to tell curl to keep cookies (if possible)

[LukasReschke]

Let me dig into the code some time… Assigning to myself.

[PVince81]

I had a quick look and our current version of Sabre wouldn't fit.

But the new Sabre version seems to come with an improved client: https://github.com/fruux/sabre-dav/blob/2.1/lib/DAV/Client.php
That one is based on the Sabre\Http\Client here: https://github.com/fruux/sabre-http/blob/master/lib/Client.php#L18 which has events "beforeRequest" and "afterRequest" that give access to the headers. This means that we could just implement those and do the cookie magic.

It also means that it's really time to upgrade Sabre... #12876

[PVince81]

🔔 the new Sabre has arrived which means it will be possible to work with the cookies now 😄

[PVince81]

Moving to 8.2

[PVince81]

@LukasReschke any update ?

[PVince81]

I guess the outcome of #5383 could also help here ?

[PVince81]

#5383 was moved to 9.1 and is likely to be helpful to solve this one here. Moving to 9.1 as well.

@cmonteroluque

[PVince81]

Pluggable auth should be able to help with this.

When connecting to a remote federated share, one would need to pass a token in the "Authorization" header. Note that for fed share there is already a token, the share one. Not sure how to integrate this better with 9.1's new token based auth. @ChristophWurst

[PVince81]

Reuse session or send an Authentication header as per #11815.

But reusing the session should reduce the burden on the remote server.

[PVince81]

There are actually two levels of reusing the session:

1. Level 1: within a single PHP request, we already do many calls to the remote server. Keeping a single session within that PHP request would already reduce the load significantly.

2. Level 2: store the session id in the database to be able to reuse it in separate PHP requests. When expired, need to refresh it. (this all somehow reminds me of OAuth...)

[PVince81]

Hmm strange thing, I just tested on master and looking at access_log I only saw a single 401 appearing instead of multiple ones. Maybe one of the Sabre upgrades brought cookie support. Need to double check this.

[PVince81]

From what I see and remember, Sabre client's HTTP layer has changed a bit. And from what I see here https://github.com/fruux/sabre-http/blob/4.2.1/lib/Client.php#L348 it might be using a single curl session, which is likely to keep cookies.

I'll check on the remote server to see if we're indeed reusing a session.
Then: identify which version this stated happening and hopefully close this ticket 😄

[PVince81]

Okay, I did some debugging on the target server and noticed that the sabre client was already sending the Authorization header for any requests that follow the one with 401. So the 401 only happens once.

Now let's see if we can also reuse the session to reduce the load even more.

[PVince81]

Now thinking of it the public webdav usually isn't supposed to have a session.
But it does have one because someone can authenticate several link shares using their password and that information is stored in the session to avoid re-auth multiple times.

So there is still a little bit to save here.

[PVince81]

Will be obsoleted by #29779

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.