Config.api.authorization_type = AWS_IAM

Jets
1

I’m setting the api authorization_type to AWS_IAM which ultimately ends up creating an API Gateway with ALL HTTP methods having Authorization of AWS_IAM including OPTIONS

My React app is using AWS Amplify for connecting to the API Gateway resources. This works great because Amplify will sign the requests with the required AWS Sig4 info to satisfy the AWS_IAM authorization.
Amplify will send out an OPTIONS request prior to the GET/PUT/POST/DELETE you are actually trying to do and unfortunately the api DOES NOT sign that OPTIONS request.
Since OPTIONS also has AWS_IAM in front of it, this results in a 403 on that request and ultimately prevents moving on to the actual request the app is trying to make.

Need some help to either get something updated or help in moving in the correct direction a solution already exists.
Possible options:

  1. Update Jets to set all OPTIONS to Authorizer = NONE
    Proably not a big deal…the OPTIONS resources are just MOCKs anyway.

  2. Assuming there is a use case for OPTIONS to have AWS_IAM, sounds like some finer grain control over Authorizers is needed. As far as I can tell, right now, you can only set it globally.
    Does finer grain control already exist?

  3. Something else/better I’m not thinking of?

2

Make sense. Done: https://github.com/tongueroo/jets/pull/170/files OPTIONS requests defaults to authorization_type = "NONE" now. Released in v1.6.3

Updated docs also: http://rubyonjets.com/docs/cors-support/

You can configure it also: config.api.cors_authorization_type = ...

There is some finer grain control. There was a way to do this before the change in PR 170 above. Can specify authorization_type at the controller level. So could had added this:

class ApplicationController < Jets::Controller::Base
  authorization_type :aws_iam
end

The authorization_type gets inherited from controllers inheriting from the ApplicationController. But would not have affected the cors OPTIONS request since that resource gets created separately as a mock, as you’ve pointed out. Wasn’t too much complexity to add, so there’s even more control now.

More info: http://rubyonjets.com/docs/routing-authorization/

Think defaulting the cors OPTIONS request to NONE, even when config.api.authorization_type = :aws_iam makes sense though and is the more common case.

Don’t think so.

3

Here’s confirmation.

$ curl -svo /dev/null "https://42utgj3qoc.execute-api.us-west-2.amazonaws.com/dev" 2>&1 | grep '< HTTP'
< HTTP/2 403 
$ curl -X OPTIONS -svo /dev/null "https://42utgj3qoc.execute-api.us-west-2.amazonaws.com/dev" 2>&1 | grep '< HTTP'   
< HTTP/2 200 
$ grep authorization_type config/application.rb 
  config.api.authorization_type = "AWS_IAM" # default is 'NONE' https://amzn.to/2qZ7zLh
$
4

Awesome…thanks @tung … Sorry for the request when the control needed already existed…I figured it might but didn’t quite see what needed to be done.
I do appreciate the update though…Jets is an awesome tool - thanks so much for putting this together.

~bb

5

Just an FYI…It isn’t looking like config.cors is defaulting to true. If I don’t explicitly add that setting, OPTIONS are not created on the API Gateway at all.

6

Yup. Changed it in the last release while I still have a chance. Figured Cors was broken before anyway before this so it’s ok.

Have had mixed feelings about having Cors defaulting to true vs false. Thinking is that it is better to go from default false to true later than vice versa.

7

That’s actually a good idea.

1 Like