-
Notifications
You must be signed in to change notification settings - Fork 689
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
Removed duplicated condition for allowedUrls during interceptor logic and make it optional #584
Conversation
This way user can define `allowedUrls` or `customUrlValidation` during module import
Took me some time, I think the title of the PR suggests only a deduplication effort, but you are in fact proposing a minor breaking change I think? That is, your new version behaves different in this example scenario:
That's intended, right? (Shame we have no tests yet, they would help a lot here...) |
Yep, the title is incorrect, I just edited it Indeed, that's what I want to achieve... right now, to make
But I expect to define this
Because I'm not interested in setup allowedUrls, just the validations function |
👍 LGTM then. Something for a major release, even though the breaking change is small. |
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.
Fixes the linked issue AFAICT.
Tiny breaking change (for the better), something for v9?
Yep, technically this PR is a breaking change. I mean, the only difference is that currently the config below does nothing while with this PR it would execute custom URL validation {
resourceServer: {
customUrlValidation: url => { /* some complex logic */ },
allowedUrls: undefined
}
} So the real question is "How likely is there someone out there currently using a pointless configuration like that?" My Two Cents |
Before this change user needed to define both
allowedUrls
andcustomUrlValidation
to makecustomUrlValidation
work, otherwise it was never executed.