File Uploaded using SDK throws 403 about acl-check HOT 9 CLOSED

OK, @justinwb gave the winning insight - it affects migrated accounts! :) that's why we are seeing it on our inrupt.net accounts but not on our dev.inrupt.net accounts. I just tried with a newly created inrupt.net account, and that's also not affected.

With that insight, it was easy to find:
https://github.com/solid/node-solid-server/blob/master/default-templates/new-account/profile/.acl
Which is the ACL that makes the profile/ folder writable and that's missing from migrated accounts.

What I don't understand is why it doesn't still allow the upload based on the root ACL doc. but at least I have been able to reproduce the problem on localhost now, by putting NSS4 account content into my localhost NSS5 instance.

from acl-check.

Seeing this happen intermittently when running the app against localhost, logging in as https://michielbdejong.localhost:8443/profile/card#me. Investigating.

from acl-check.

It worked 10 times in a row, then I logged out and back in, and got a 401 (not 403) error.

from acl-check.

Right, the 401 error happens because it tries the PUT without credentials, then it retries it with credentials, and does succeed. This only happens the first time after you've logged in.

from acl-check.

OK, sorry for the confusion. The 401 errors are unrelated. I can reproduce this on inrupt.net but not on dev.inrupt.net, nor solid.community, nor on localhost.
I had a look on the server and there's nothing wrong there. The errors don't show up in sudo journalctl -f -u solid either.

Will think about it for a bit.

from acl-check.

Just encountered the same, trying to send a PUT request from localhost:3000 to NSS running at localhost:8443, got the same error:

  You are currently logged in as <code>https://localhost:8443/profile/card#me</code>,
  but do not have permission to access <code>https://localhost:8443/index.html~</code>.

from acl-check.

Great! I don't have time to test it yet, but I encountered this error with a freshly created user after bin/solid-test init, so there might be a code path that needs updating there as well.

from acl-check.

Right, the problem is that the trustedApp check chokes on the acl:agent <mailto:...>; line (I guess it tries to dereference that to find out what the trusted apps for that email address are.

from acl-check.

Ah wow, duplicate of #24 even.

from acl-check.