inrupt / inrupt/solid-client-js

setPublicAccess from universalAccess not working as expected

Open
#1,640 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
TypeScript
Stars
245
Forks
42
Avg merge
12h 49m
Merged PRs (30d)
22

Description

Bug description

SetPublicAccess doesn’t return null, but returns an access object that is unchanged.

To Reproduce

(the pod used to get this bug is hosted on https://pod.inrupt.com/)

  1. Create a new container
  2. try to use setPublicAccess to set a new public access type on the created container (e.g: {read:true, write: true}
  3. assign the return to some variable
  4. check value of that variable, it would have read: false and write: false

Minimal reproduction

https://codesandbox.io/s/great-tharp-qzznwy?file=/src/index.ts

Expected result

The expected result is:

  1. null returned in case if you don't have rights to change access to the resource.
  2. an access object with values that were passed to the function (on return)
Actual result

an access object with everything set to false was returned (while read: true and write: true were passed to the function)

Environment

System:
OS: macOS 10.15.7
CPU: (4) x64 Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
Memory: 47.77 MB / 4.00 GB
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 16.14.0 - ~/.nvm/versions/node/v16.14.0/bin/node
npm: 8.3.1 - ~/.nvm/versions/node/v16.14.0/bin/npm
Browsers:
Chrome: 102.0.5005.61
Safari: 15.5
npmPackages:
@babel/core: ^7.17.9 => 7.17.9
@babel/preset-env: ^7.16.11 => 7.16.11
@babel/preset-react: ^7.16.7 => 7.16.7
@babel/preset-typescript: ^7.16.7 => 7.16.7
@inrupt/lit-generated-vocab-common: ^0.3.11 => 0.3.11
@inrupt/solid-client: ^1.23.1 => 1.23.1
@inrupt/solid-client-access-grants: ^1.0.1 => 1.0.1
@inrupt/solid-client-authn-browser: ^1.11.7 => 1.11.7
@inrupt/solid-ui-react: ^2.7.0 => 2.7.0
@inrupt/vocab-common-rdf: ^1.0.3 => 1.0.3
@types/jest: ^27.4.1 => 27.4.1
@types/node: ^17.0.23 => 17.0.23
@types/react: ^18.0.2 => 18.0.2
@types/react-dom: ^18.0.0 => 18.0.0
assert: ^2.0.0 => 2.0.0
babel-loader: ^8.2.4 => 8.2.4
bootstrap: ^5.1.3 => 5.1.3
buffer: ^6.0.3 => 6.0.3
css-loader: ^6.7.1 => 6.7.1
gh-pages: ^3.2.3 => 3.2.3
html-webpack-plugin: ^5.5.0 => 5.5.0
rdf-namespaces: ^1.9.2 => 1.9.2
react: ^18.0.0 => 18.0.0
react-bootstrap: ^2.2.3 => 2.2.3
react-dom: ^18.0.0 => 18.0.0
react-icons: ^4.3.1 => 4.3.1
solid-file-client: ^2.1.3 => 2.1.3
style-loader: ^3.3.1 => 3.3.1
ts-loader: ^9.2.8 => 9.2.8
typescript: ^4.6.3 => 4.6.3
webpack: ^5.72.0 => 5.72.0
webpack-cli: ^4.9.2 => 4.9.2
webpack-dev-server: ^4.8.1 => 4.8.1
npmGlobalPackages:
corepack: 0.10.0
create-react-app: 5.0.0
java: 0.12.2
jest: 27.5.1
npm: 8.3.1
typescript: 4.6.2

Additional information

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the setPublicAccess entry point and reproduce the behavior using the linked CodeSandbox with a newly created container. Check the return value both without permission and when passing read:true and write:true. Done means unauthorized changes return null and authorized changes return an access object reflecting the requested values.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
authorization
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.