Skip to content

Conversation

randikabanura
Copy link

resolves #471

return false unless expected_origin

expected_origin.include?(client_data.origin)
Array(expected_origin).any? { |allowed_origin| allowed_origin === client_data.origin }
Copy link
Author

Choose a reason for hiding this comment

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

Copy link
Contributor

@santiagorodriguez96 santiagorodriguez96 left a comment

Choose a reason for hiding this comment

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

Great start! I still have some concerns about this that I shared in the respective issue (#471) but I think it's a great idea to add this

return false unless expected_origin

expected_origin.include?(client_data.origin)
Array(expected_origin).any? { |allowed_origin| allowed_origin === client_data.origin }
Copy link
Contributor

Choose a reason for hiding this comment

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

chore: although it's not implied by the name of the variable, expected_origin is, in fact, already an array so we can avoid the conversion:

Suggested change
Array(expected_origin).any? { |allowed_origin| allowed_origin === client_data.origin }
expected_origin.any? { |allowed_origin| allowed_origin === client_data.origin }

Comment on lines +118 to +120
return unless valid_origin?(expected_origin)

URI.parse(client_data.origin).host if expected_origin.size == 1
Copy link
Contributor

Choose a reason for hiding this comment

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

issue: I see why we have to do this, but I don't think we should be changing the rpId depending on the origin of the request. After all, the credentials are scoped to the rpId so by doing this we will be generating credentials scoped to the different origins.

If that's desired, I think users of this gem should instead use our instance based configuration for handling this.

However, I think we have other options similar to what we did when we added the support for declaring multiple allowed origins: we could assume we won't be able to infer the rpId correctly if a wildcard origin is used so we just simply don't do it – which will force the users of the gem to explicitly set it in their configuration.

What do you think?

Comment on lines +163 to +165
def fake_wildcard_origin
/http:\/\/localhost.*/
end
Copy link
Contributor

Choose a reason for hiding this comment

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

chore: this is not used, right? Should we remove it or was it added for a particular reason?


let(:origin) { fake_origin }
let(:actual_origin) { origin }
let(:origin) { fake_wildcard_origin }
Copy link
Contributor

Choose a reason for hiding this comment

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

suggestion: I would keep the "normal" origin declaration here and just add an additional context under the "origin validation" section. What do you think?

end

def fake_wildcard_origin
/http:\/\/localhost.*/
Copy link
Contributor

@santiagorodriguez96 santiagorodriguez96 Aug 22, 2025

Choose a reason for hiding this comment

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

thought: perhaps we should document in some way that, in order for wildcard domains to work, a regexp should be provided.

From the Rails' guides I found that they do it for ActionCable's allowed_request_origins:

Action Cable will only accept requests from specified origins, which are
passed to the server config as an array. The origins can be instances of
strings or regular expressions, against which a check for the match will be performed.

config.action_cable.allowed_request_origins = ["https://rubyonrails.com", %r{http://ruby.*}]

What do you think?

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.

Wildcard urls for allowed_origins

2 participants