Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This was previously enabled in PR #1375 but then reverted in PR #1383 when it was discovered that enabling it had silently broken the ability for Release API clients to create deployment records because they don't (and shouldn't need to) send the CSRF token in the request. I'm avoiding the problem seen in PR #1375 by skipping forgery protection if we detect a Bearer token in the Authorization HTTP Header. I'm doing this in the same way that GDS::SSO checks whether the `gds_sso` Warden strategy is valid[1] or whether it needs to use the `gds_bearer_token` strategy instead[2] so I'm fairly confident this is good enough to distinguish an API request from a browser request. One of the two new controller tests should fail if we either: - remove the `with: :exception` option to `protect_from_forgery` - require the CSRF token when an API client authenticates using a Bearer token and creates a deployment Note that I'm assuming that `Deployments#create` is the only API endpoint. If it turns out there are more API endpoints then we'll need to make the same change to those. I was interested to learn that raising an exception is the default behaviour in new Rails apps[3] but that we were overriding that default with our explicit call to `protect_from_forgery` without any arguments. Adding `protect_from_forgery with: :exception` is the same as removing `protect_from_forgery` entirely, although I think the former is more explicit. [1]: https://github.com/alphagov/gds-sso/blob/8cc1427bfcd3cbfa24904040c8eaccff45434322/lib/gds-sso/warden_config.rb#L38 [2]: https://github.com/alphagov/gds-sso/blob/8cc1427bfcd3cbfa24904040c8eaccff45434322/lib/gds-sso/warden_config.rb#L64 [3]: https://guides.rubyonrails.org/security.html#required-security-token
- Loading branch information