Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: IpfsApiAccessError #458

Merged
merged 8 commits into from
Apr 30, 2018
Merged

Feat: IpfsApiAccessError #458

merged 8 commits into from
Apr 30, 2018

Conversation

JonKrone
Copy link
Contributor

Use a common Error type, IpfsApiAccessError, when an app is denied access to a window.ipfs api.

Discussed in #455.

Remaining:

This also fixes some path.sep related test failures on Windows, lemme know what you think about that.

@JonKrone
Copy link
Contributor Author

Make this type available somewhere under window.ipfs. Perhaps the ipfs.types or ipfs.utils
from #444?

Looking for thoughts here.

@lidel
Copy link
Member

lidel commented Apr 16, 2018

Browserify issue?

While it seems to work in tests, real life version injected as content script does not seem to produce Error with additional attributes. Try executing this against some website (and deny access to trigger error):

ipfs.files.add(Buffer.from('seed')).catch(e => console.log(`Error.permission=${e.permission}, scope=${e.scope}, message=${e.message}`))

I get:

screenshot_4

Are you able to reproduce?

Namespace for proxy-specific stuff

The ipfs.types sounds like an obvious place, but I am worried about unexpected consequences of polluting original interface-ipfs-core API namespaces with proxy-specific stuff.

Perhaps a safer alternative is to use window.ipfs.proxy (idea suggested in #454 (comment)) and expose it at ipfs.proxy.types.IpfsApiAccessError.

@olizilla @alanshaw do we have any strong opinions or preferred conventions for handling this?

@alanshaw
Copy link
Member

Yes, I posted my comments here #455 (comment)

@alanshaw
Copy link
Member

alanshaw commented Apr 16, 2018

On the posix stuff, I did check this originally because it needs to be posix.

The path module as included by browserify is https://github.com/substack/path-browserify/blob/master/index.js which seems to be using the posix versions and doesn't include a path.posix.

@lidel
Copy link
Member

lidel commented Apr 16, 2018

@JonKrone to limit the number of moving pieces, let's go with version proposed by @alanshaw in #455 (comment) (no new type, just a self-explanatory property):

if (err.isIpfsProxyAclError) {

That way we don't have to change anything on the backend and we don't need to think where to put the new type.

@JonKrone JonKrone force-pushed the feat/api-access-error branch from 0e800fe to 3ad9eeb Compare April 19, 2018 16:23
@JonKrone
Copy link
Contributor Author

Hey guys, I'm sorry for the delay! I was totally swamped last week.

I pushed some changes a few days ago, thanks @alanshaw for the solution with ipfs-postmsg.

re: the posix path fix for tests on Windows: I explicitly imported path-browserify. We could alternatively manually normalize the paths, let me know what you think.

Copy link
Member

@lidel lidel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! The key properties that address needs raised in #455 look goood 👌

screenshot_1

Small details remain to be fixed before we merge it, see below.

@@ -1,4 +1,5 @@
const Path = require('path')
// Use path-browserify for consistent behavior between browser and tests on Windows
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think explicitly using path-browserify (which provides posix version by default) is bit safer than assuming browserify-ing process will swap the implementation.

Let's merge this, and if at some point path-browserify turns out to be not enough, we can swap it with own implementation / wrapper.

@alanshaw does it sound ok to you?

} catch (err) {
if (err.isIpfsProxyAclError) {
// Fallback
console.log(':(')
Copy link
Member

@lidel lidel Apr 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would replace console.log(':(') with console.log('Unable to get ACL decision from user :(', err) to make it more obvious for first-timers :)

Tests were not running because some path parser didn't understand
apostrophes so I've just converted those to escaped quotes.

Some pre-mfs-scope tests failed because path.join presumes we want paths
for the current running OS. I changed it to always use posix paths but
I'm open to arguments that changing the implementation is a better
approach. All of our target environments use posix paths, I believe.
@JonKrone JonKrone force-pushed the feat/api-access-error branch from f3e8d9e to a840622 Compare April 27, 2018 13:01
Copy link
Member

@lidel lidel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry it took so long to review this :)

Doc with err.isIpfsProxyAclError looks good, let's merge this.

@lidel lidel merged commit 3241731 into ipfs:master Apr 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants