-
Notifications
You must be signed in to change notification settings - Fork 116
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
Validate redirect uris are parsable uris #1762
Changes from 4 commits
c38b31c
28188fd
8884844
60f7fb6
c52ef87
ea47b3e
17085c8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,27 @@ | ||
require 'rails_helper' | ||
|
||
describe ServiceProvider do | ||
describe 'validations' do | ||
it 'validates that all redirect_uris are absolute, parsable uris' do | ||
valid_sp = build(:service_provider, redirect_uris: ['http://foo.com']) | ||
missing_protocol_sp = build(:service_provider, redirect_uris: ['foo.com']) | ||
empty_uri_sp = build(:service_provider, redirect_uris: ['']) | ||
relative_uri_sp = build(:service_provider, redirect_uris: ['/asdf/hjkl']) | ||
bad_uri_sp = build(:service_provider, redirect_uris: [' http://foo.com']) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is that space before http there for a reason? That's what's making it a bad url? If so, maybe we could think of something that would be more clear. Like maybe 'hXttp'? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ruby's URI module specifies between "Bad" and "Invalid" URIs. An Invalid URI is one that does not match against the URI regex. A bad URI is a URI that matches against the regex, but doesn't work when used in practice (e.g. it raises when passed to Adding the space at the beginning of the URI was the most obvious way I could think of to raise a |
||
|
||
expect(valid_sp).to be_valid | ||
expect(missing_protocol_sp).to_not be_valid | ||
expect(empty_uri_sp).to_not be_valid | ||
expect(relative_uri_sp).to_not be_valid | ||
expect(bad_uri_sp).to_not be_valid | ||
end | ||
|
||
it 'allows redirect_uris to be blank' do | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we also add a test to make sure redirect_uris cannot be an empty string? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And also a test to make sure that any extra spaces get trimmed. If somehow the dashboard passes in a URI such as There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that we want to fail if there are spaces around the uri. The failure would alert us to a bug in how the dashboard is saving redirect uris. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I see you already covered those. I couldn't easily see the extra space in GitHub's unified view. I'm fine with treating the extra space as an error. |
||
sp = build(:service_provider, redirect_uris: nil) | ||
expect(sp).to be_valid | ||
end | ||
end | ||
|
||
describe '#issuer' do | ||
it 'returns the constructor value' do | ||
sp = ServiceProvider.from_issuer('http://localhost:3000') | ||
|
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.
If the URI contains spaces, it will fail (as expected), but we can easily fix that before we parse the URI. From a UX perspective, I think it's better for us to fix formatting issues for the user. This would mean a
before_validation
callback that calls.strip
on the URI. I'm generally not crazy about callbacks, but I think it's fine in this situation since it only operates on the ServiceProvider object. Thoughts?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.
The user here is the dashboard app which should not be sending us malformed URLs. I agree that we should be removing spaces from the URLs for the user, but we should be doing that on the dashboard before we write them into the db, and not in the IDP.
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.
If there is validation/enforcement we can move to the dashboard instead to guarantee structure of the API output, happy to do that so we don't have to build some elaborate guards in the IdP.