public links do not work in private/incognito windows

[individual-it]

Steps to reproduce

1. create a public link
2. open that public link in a private window (FF) or incognito window (Chrome)

Expected behaviour

files / folders should be listed

Actual behaviour

empty file-list

Logs

Browser log (FF)

TypeError: "e.files_sharing is undefined"
    enabled http://172.17.0.1:8300/apps/files/files.bundle.js:22
    actions http://172.17.0.1:8300/apps/files/files.bundle.js:7
    get http://172.17.0.1:8300/core/core.bundle.js:13
    evaluate http://172.17.0.1:8300/core/core.bundle.js:13
    _n http://172.17.0.1:8300/core/core.bundle.js:13
    A http://172.17.0.1:8300/apps/files/files.bundle.js:22
    me http://172.17.0.1:8300/core/core.bundle.js:13
    A http://172.17.0.1:8300/apps/files/files.bundle.js:22
    _render http://172.17.0.1:8300/core/core.bundle.js:13
    r http://172.17.0.1:8300/core/core.bundle.js:13
    get http://172.17.0.1:8300/core/core.bundle.js:13
    run http://172.17.0.1:8300/core/core.bundle.js:13
    hn http://172.17.0.1:8300/core/core.bundle.js:13
    te http://172.17.0.1:8300/core/core.bundle.js:13
    Jt http://172.17.0.1:8300/core/core.bundle.js:13
    Z http://172.17.0.1:8300/core/core.bundle.js:55
    r http://172.17.0.1:8300/core/core.bundle.js:61
core.bundle.js:13:11524
    Vt http://172.17.0.1:8300/core/core.bundle.js:13
    Ut http://172.17.0.1:8300/core/core.bundle.js:13
    zt http://172.17.0.1:8300/core/core.bundle.js:13
    _render http://172.17.0.1:8300/core/core.bundle.js:13
    r http://172.17.0.1:8300/core/core.bundle.js:13
    get http://172.17.0.1:8300/core/core.bundle.js:13
    run http://172.17.0.1:8300/core/core.bundle.js:13
    hn http://172.17.0.1:8300/core/core.bundle.js:13
    te http://172.17.0.1:8300/core/core.bundle.js:13
    Jt http://172.17.0.1:8300/core/core.bundle.js:13
    Z http://172.17.0.1:8300/core/core.bundle.js:55
    r http://172.17.0.1:8300/core/core.bundle.js:61

Browser log (Chrome)

TypeError: Cannot read property 'public' of undefined
    at Object.enabled (files.bundle.js:22)
    at s.actions (files.bundle.js:7)
    at dn.get (core.bundle.js:13)
    at dn.evaluate (core.bundle.js:13)
    at s.actions (core.bundle.js:13)
    at files.bundle.js:22
    at s.me [as _l] (core.bundle.js:13)
    at s.<anonymous> (files.bundle.js:22)
    at s.t._render (core.bundle.js:13)
    at s.r (core.bundle.js:13)

[individual-it]

the problem seems not to be a private session but a session where there hasn't been an phoenix authentication before.
A new session of the browser e.g. private or container tab (in FF) cannot access the public link, when the user opens phonix and logs in, the public link works (with problems e.g. all items are marked as favorite). then the user can logout of the session (not from the public link) and the public link still works.
But if there hasn't been a session ever, the public link shows the errors above.

#1900 hasn't changed anything in that problem

[PVince81]

we should investigate this as it could hide more issues

[PVince81]

reproduced locally while attempting to write public link tests without going through the auth pages

[PVince81]

raising to p2. this means people who never had an OC account and are trying to open a public link will see this error

[PVince81]

This is related to capabilities. We need to make sure that any code that relies on capabilities can still work even when they are not loaded.

[PVince81]

Fix is here: #2110

[PVince81]

This also tells me that capabilities are likely still stored somewhere after a user has logged out.
We likely don't properly clear things @LukasHirt @DeepDiver1975

[PVince81]

From what I see the current user object is stored in localStorage, including capabilities.

And when we log out, we do reset all user vars to something like false or null, but the capabilities are staying untouched and uncleared.

[DeepDiver1975]

but the capabilities are staying untouched and uncleared.

capabilities are reset here - at least in theory
https://github.com/owncloud/phoenix/blob/f03a65410eb143b706da939c4727df3d2d4bab19/src/store/user.js#L22

[PVince81]

@DeepDiver1975 from what I'm currently seeing, the capabilities are also present in the user object.
Two lines above we set the user to the default state which, as I can see in the console, contains no capabilities. Still, it seems vuex-persist seems to not want to overwrite the user.capabilities with that.

I could also try rewiring SET_CAPABILITIES to also commit to the user object.
Or we move the capabilities to another level in the store, in an own store module.

[PVince81]

additional note: @DeepDiver1975 what you pointed at does work temporarily, but as soon as the vuex-persist restores the state from localStorage where the user.capabilities is still set, it will overwrite the null with the persisted array.

[PVince81]

okay, now I understand. SET_USER is not even reading the capabilities property, but SET_CAPABILITIES does.

now the question is why vuex-persist is not persisting null as capabilities in localStorage while doing SET_CAPABILITIES

[PVince81]

I tried a little hack where I clear capabilities and version within the "SET_USER" call and it works now.

Another try: I have swapped SET_CAPABILITIES and SET_USER and now it works ?!

To analyze further, I added a dummy attribute in the state. If I set said property in SET_USER, its value is persisted in localStorage. However if I set another value for dummy in SET_CAPABILITIES, it does not get persisted to localStorage.

This tells me that somehow vuex-persist only triggers for SET_USER but not for SET_CAPABILITIES.

Might need to read more about vuex-persist to find out why it's only persisting the first one.

[PVince81]

and found it... there is a filter indeed for vuex-persist... I'll make a PR.

[PVince81]

Fix for properly clearing capabilities is here: #2116