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

Checks on resourceid (Public Links) #2494

Merged
merged 4 commits into from
Dec 10, 2019
Merged

Conversation

refs
Copy link
Member

@refs refs commented Nov 19, 2019

Description

Gets rid of share id type checking

Motivation and Context

Reva id's are strings, therefore this guard is preventing them from being rendered.

How Has This Been Tested?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)

@refs refs requested a review from DeepDiver1975 as a code owner November 19, 2019 12:44
@refs
Copy link
Member Author

refs commented Nov 19, 2019

not entirely sure of the implications of removing that equality statement, should instead be checked whether the id is null? Bottom line is this guard is assuming id's are integers, where they could be strings now (depending on the back end) so perhaps this is just a band-aid on a wider issue

@PVince81
Copy link
Contributor

@refs can you instead remove the parseInt() but keep a strict equality there so that it becomes a string comparison ? This will also assume that the file ids are strings as well.

There is a slight risk of breakage as I noticed that in many places in Phoenix some values are not consistently converted (or not converted) to integers. CI will tell.

@PVince81
Copy link
Contributor

also note: the code in question does not refer to the share ids but to the id of the source that is shared, here a file id. The actual share id is in another attribute, probably link.id.

@refs
Copy link
Member Author

refs commented Nov 19, 2019

also note: the code in question does not refer to the share ids but to the id of the source that is shared, here a file id. The actual share id is in another attribute, probably link.id.

Ah, yes, I meant resource id. Getting used to the domain terminology 💃

@CLAassistant
Copy link

CLAassistant commented Nov 20, 2019

CLA assistant check
All committers have signed the CLA.

@refs
Copy link
Member Author

refs commented Nov 20, 2019

@PVince81 I realized the initial state of the PR completely breaks the public share listing later on. In order to support both oc10 + ocis that filter should work both on autoincrement ids (oc10) and base64[1] resourceid[2].

Whether this works with oc10 we'll see on CI (haven't tested locally, only reva).

@refs refs changed the title get rid of shareid type check filter Checks on resourceid (Public Links) Nov 20, 2019
@refs refs mentioned this pull request Nov 20, 2019
3 tasks
@PVince81
Copy link
Contributor

Hmm, seems CI is green. so this likely means that we're lucky and both file ids and share ids are strings already in all places.

@@ -100,6 +100,16 @@ export default {
})
})
},
compareIds (x, y) {
if (!isNaN(x)) { // OC10 autoincrement id
return parseInt(x) === parseInt(y)
Copy link
Contributor

@PVince81 PVince81 Nov 22, 2019

Choose a reason for hiding this comment

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

parseInt(x, 10) === parseInt(y, 10). without this leading zeroes would cause Javascript to parse numbers as octal...

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, I was was aware of the radix problem but was blatantly relying on ES5 definition:

If radix is undefined or 0, it is assumed to be 10 except when the number begins with the character pairs 0x or 0X, in which case a radix of 16 is assumed. If radix is 16, the number may also optionally begin with the character pairs 0x or 0X.

the definition applies also on Number ES6:

This method has the same functionality as the global parseInt() function:

Number.parseInt === parseInt; // true

and is part of ECMAScript 2015 (its purpose is modularization of globals). Please see parseInt() for more detail and examples.

In any case, a check for hex would make it less error prone, but octal should not be a concern, unless someone's using a version older than ES5... .

In any case, to make things clear I'd add the radix 💃

compareIds (x, y) {
if (!isNaN(x)) { // OC10 autoincrement id
return parseInt(x) === parseInt(y)
} else if (atob(y).split(':').length === 2) { // OC10: https://github.com/cs3org/reva/blob/e7830e2f752a05a081178ed26c384ced983b8fde/internal/http/services/owncloud/ocdav/ocdav.go#L169-L175
Copy link
Contributor

Choose a reason for hiding this comment

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

if this is something we'll do more in the future for extracting the id, maybe we need a separate function for just extraction ?

something like {x, y, z, ...} = extractCS3IdParts(id) (not sure how many parts it has)

Copy link
Contributor

Choose a reason for hiding this comment

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

now thinking, maybe this should me done on SDK level. The SDK is here to abstract away whether Webdav, OCS or CS3 is being used to avoid having API-specific logic in the frontend code.

@DeepDiver1975 thoughts ?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not entirely sure this is going to stay this way, perhaps @butonic can shed a bit more light, as the only place I found this requirement is alone in the reva code

Copy link
Contributor

Choose a reason for hiding this comment

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

@butonic any comments here ?

if we don't know let's add a "TODO: move to common location or library" then

@refs refs requested a review from PVince81 November 25, 2019 09:50
@refs
Copy link
Member Author

refs commented Nov 28, 2019

bump, before this gets stale. Is this safe to merge or requires more deliberation?

@PVince81
Copy link
Contributor

@refs I suggest to move the id splitting logic to a helper function, maybe call it "splitOcisId" or "splitCs3Id" just to make sure future developers won't scratch their head about why there are two code parts. Make it return null if no such id format was detected

Then we can ship this and discuss later whether to keep this method or not.

Copy link
Contributor

@PVince81 PVince81 left a comment

Choose a reason for hiding this comment

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

👍

@refs refs self-assigned this Dec 9, 2019
@refs refs merged commit 6c9a647 into owncloud:master Dec 10, 2019
@refs refs deleted the fix-shareid-type-check branch December 10, 2019 08:46
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