-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Log error instead of throwing security exception #6363
Log error instead of throwing security exception #6363
Conversation
object PathUtils { | ||
|
||
@JvmStatic | ||
fun getRelativeFilePath(dirPath: String, filePath: String): String { | ||
return if (filePath.startsWith(dirPath)) filePath.substring(dirPath.length + 1) else filePath | ||
} | ||
|
||
@JvmStatic | ||
fun getAbsoluteFilePath(dirPath: String, filePath: String): String { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to move this whole method to the androidshared
module because the shared
one is a pure java/kotlin module and I can't use Timber or Analytics there. I've tried SLF4J
to no avail. I think we should file an issue to figure out how to log things in such modules.
assertThat(path, equalTo(nonCanonicalPath + File.separator + "file")) | ||
} | ||
// @Test | ||
// fun `getAbsoluteFilePath() returns filePath prepended with dirPath`() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this as well and just ignore the tests for the SecurityException
?
a091036
to
e3f3d60
Compare
…eption Log error instead of throwing security exception
…eption Log error instead of throwing security exception
…eption Log error instead of throwing security exception
Why is this the best possible solution? Were any other approaches considered?
As we discussed on slack with @seadowg there is something wrong with the way analyze paths and throw the
SeciurityException
so we should stop doing that (throwing the exception) until we know what is going on there and can properly fix the code.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
It doesn't require testing.
Do we need any specific form for testing your changes? If so, please attach one.
No.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest
(or./gradlew testLab
) and confirmed all checks still passDateFormatsTest