[Owncloud] [core] upload >100k not finished (#1006)

[Christian Reiner]

Hello, 
sorry again, but as mentioned before I currently do not have time to work 
myself into that implementation again. I think it is more fair to clearly 
state this. I hope that is the right way to go...

On Sunday 23 December 2012 14:23:30 lassi wrote:
> I've got more information: It looks like the "lifebeat" doesn't work at all
> because the session expires before it is issued.
> 
> I retested the upload, this time with response body logging enabled, and
> already response of the first lifebeat request indicates an authentication
> error:
> 
> ```
> {"data":{"message":"Authentication error"},"status":"error"}
> ```
> 
> Here's the request log:
> 
> ```
> [16:15:14.051] POST https://foo.bar/?app=files&getfile=ajax%2Fupload.php
> [17:10:41.999] refreshing request token (lifebeat)      core.js:318
> [17:10:42.137] POST https://foo.bar/core/ajax/requesttoken.php [HTTP/1.1 200
> OK 797ms] ```
> 
> The session had already timed out at this point, opening a new tab on that
> owncloud instance send me to the login page! It seems that the session
> timeout is shorter than the lifebeat interval.

When I implemented the more flexible solution if handling request tokens 
(which contained a lifebreat implementation) I tested and verified that things 
worked as expected. My motivation for the implementation were similar problems 
to the one mentioned here, but not the same: for me those apps that do _not_ 
require regular full reloads, but that load once when being selected and then 
work purely on the client side (except for ajax requests) suffered from the 
problem of CSRF protection token expiries. For example when my Shorty app was 
left alone for some hours without closing the browser. I thought it makes 
absolutely no sense to have a fully functional app already loaded in the 
browser, ready to be used, but still being presented a silly "please reload" 
message upon the first action. If I am asked to reload just to get a fresh 
CSRF protection token, then I can have a routine do that for me. There is no 
difference in that frm a security point of view.
Back then the problem was not a session timeout, but a timeout of the request 
tokens. Those tokens were limited to 1 hour back then and I was told a few 
times in discussions that it was considered very important to have a limited 
lifetime of such CSRF tokens. So what I did instead of increasing the tokens 
lifetime was to implement a mechanism that would refresh the tokens right 
before they would expire. That is what I called lifebeat. It had nothing to do 
with the session itself. 

In the meantime the request token implementation has been completely redone. 
My strategy of a pool of tokens and a lifebeat to fetch a fresh token before 
the current one expires does not exist any more. Instead, if I understood 
correct, there is now a single token per session, a token that never expires 
and which is used in all views opened inside a users session. The former 
lifebeat does not make any sense any more in that strategy. Either it is a 
leftover of my previous implementation which should have been removed when the 
token handling was reimplemented, or it is some other mechanism, something 
that really deals with sessions and not with request tokens. 

Either way I guess there is little I can contribute. It would be best if the 
code is reviewed by whoever implemented the current strategy. 

Christian Reiner (arkascha)