Support OPTIONS in routes #387

Closed
seancorfield opened this Issue Oct 21, 2015 · 6 comments

Comments

Projects
None yet
1 participant
@seancorfield
Member

seancorfield commented Oct 21, 2015

Whilst you can add "$OPTIONS*" = "/main/options" and hand back a canned response for preflight checks, it would be much better to be able to enable this for all routes and actually return the allowed verbs specific to each route as well as be able to specify the headers / credentials stuff.

@seancorfield seancorfield self-assigned this Oct 21, 2015

@seancorfield seancorfield added this to the 3.6 milestone Oct 21, 2015

@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Oct 31, 2015

Member

This would also need to be baked into the resource template stuff.

Member

seancorfield commented Oct 31, 2015

This would also need to be baked into the resource template stuff.

@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Nov 14, 2015

Member

Here's a canned-response preflight function just to show what might be returned:

function preflight( rc ) {
    var resp = getPageContext().getResponse();
    resp.setHeader( "Access-Control-Allow-Origin", "*" );
    resp.setHeader( "Access-Control-Allow-Methods", "GET, OPTIONS, POST" );
    resp.setHeader( "Access-Control-Allow-Headers", "Accept,Authorization,Content-Type" );
    resp.setHeader( "Access-Control-Allow-Credentials", "true" );
    resp.setHeader( "Access-Control-Max-Age", "1728000" );
    variables.fw.renderData( "text", "" );
}

Any/all portions of this should be overridable. The methods should reflect what is configured in any matching route (this part is hard since we don't currently track this if the method does not match).

Member

seancorfield commented Nov 14, 2015

Here's a canned-response preflight function just to show what might be returned:

function preflight( rc ) {
    var resp = getPageContext().getResponse();
    resp.setHeader( "Access-Control-Allow-Origin", "*" );
    resp.setHeader( "Access-Control-Allow-Methods", "GET, OPTIONS, POST" );
    resp.setHeader( "Access-Control-Allow-Headers", "Accept,Authorization,Content-Type" );
    resp.setHeader( "Access-Control-Allow-Credentials", "true" );
    resp.setHeader( "Access-Control-Max-Age", "1728000" );
    variables.fw.renderData( "text", "" );
}

Any/all portions of this should be overridable. The methods should reflect what is configured in any matching route (this part is hard since we don't currently track this if the method does not match).

@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Nov 14, 2015

Member

I'm thinking that adding a boolean preflightsOptions (default false) than when enabled provides built-in OPTIONS support, and an optionsAccessControl struct (default {}) that lets you specify overrides for origin : "*", methods : "GET, OPTIONS, POST", headers : "Accept,Authorization,Content-Type", credentials : true, maxAge : 1728000 values. The methods value will be used if no specific methods are given in routes.

Member

seancorfield commented Nov 14, 2015

I'm thinking that adding a boolean preflightsOptions (default false) than when enabled provides built-in OPTIONS support, and an optionsAccessControl struct (default {}) that lets you specify overrides for origin : "*", methods : "GET, OPTIONS, POST", headers : "Accept,Authorization,Content-Type", credentials : true, maxAge : 1728000 values. The methods value will be used if no specific methods are given in routes.

@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Nov 14, 2015

Member

For processRoutes(), I'll need to track the methods in non-matches (where the route itself does match) and accumulate a struct of such things). That might match multiple routes but I don't think the framework can (or should) do anything to restrict that.

Member

seancorfield commented Nov 14, 2015

For processRoutes(), I'll need to track the methods in non-matches (where the route itself does match) and accumulate a struct of such things). That might match multiple routes but I don't think the framework can (or should) do anything to restrict that.

seancorfield added a commit that referenced this issue Nov 14, 2015

First cut of #387
preflightOptions, optionsAccessControl implemented. Route matching and
non-route matching implemented. Renders data for options requests if
preflightOptions enabled.

Tests present for route matching.

Need to write tests for overall HTTP OPTIONS requests.
@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Nov 20, 2015

Member

This has now been integrated into the World Singles code base for more extensive QA internally. If no issues arise, I'll close this out and update the documentation.

Member

seancorfield commented Nov 20, 2015

This has now been integrated into the World Singles code base for more extensive QA internally. If no issues arise, I'll close this out and update the documentation.

@seancorfield

This comment has been minimized.

Show comment
Hide comment
@seancorfield

seancorfield Nov 21, 2015

Member

Seems to be working appropriately. Closing.

Member

seancorfield commented Nov 21, 2015

Seems to be working appropriately. Closing.

This was referenced Nov 30, 2015

webonix added a commit to webonix/fw1 that referenced this issue Dec 1, 2015

Update Application.cfc
added
preflightsOptions  = 'true',

based on
framework-one#387
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment