Hi Andrew,
First off, thanks for your help on this issue. My response is pretty long. I might have this working by the way, but I’m not 100% sure if I’m going the best route.
I’m using the base SES interceptor the comes with Coldbox 3.5.2. My routes file is pretty simple and looks like this:
`
with(pattern="/VendorAPI", handler=“rest.”)
//Clients
.addRoute(pattern="/clients/:client_id/emps",handler=“Emps”,action={
GET = “getEmpsByClientId”
})
…
.endWith();
`
I have no explicit ‘OPTIONS’ defined in any of my route actions.
I put together a custom interceptor called ‘OptionsInterceptor’. This new interceptor has one interception point called onRequestCapture, which looks like this:
`
<---************************************************************************ --->
<---************************************************************************ --->
/*
We check to see if the http method is OPTIONS, if it is we redirecto to the interceptor's redirectto property
*/
var redirectto = getProperty('redirectto');
if(event.getHTTPMethod() eq “OPTIONS”){
event.overrideEvent(redirectto);
return true;
}
return false;
`
My interceptors declaration in Coldbox.cfc is this:
`
//Register interceptors as an array, we need order
interceptors = [
//OPTIONS Interceptor
{
class=“interceptors.OptionsInterceptor”,
properties = {
redirectto=“rest.Clients.getHTTPOPtions”
}
},
//SES
{class=“coldbox.system.interceptors.SES”}
];
`
Basically my OptionsInterceptor gets the onRequestCapture announcement first. If the HTTP method is OPTIONS it sets the Event to be ‘Rest.Client.getHTTPOptions’ which is exactly what I want. This method will return true if the HTTP method is OPTIONS, thereby preventing other interceptors in the chain from executing which in this case is the SES Interceptor. This is important because if the SES Interceptor does execute then it will attempt to look up my original route and see if the route will has an action defined for the OPTIONS verb which will cause the SES interceptor to throw an error. If the HTTP method is something other than OPTIONS then OptionsInterceptor.onRequestCapture return false thereby letting the SES interceptor function as normal.
This approach gets me what I need but there are a couple of issues:
- Because I’m breaking the interceptor execution chain on my onRequestCapture event, does this mean I’m breaking the execution chain for all interceptors regardless of interception point, or just breaking it for any interceptor that is registered for the onRequestCapture event. Currently this isn’t a big deal as I don’t have any other interceptors.
- Because I’m never getting to the SES interceptor with an OPTIONS method, there isn’t a way to validate if the route is actually a valid one or not. Not a huge deal but it would be nice if I had this.
I have considered going a different way with my custom interceptor where instead of returning true if its an OPTIONS method, I add a variable into the rc collection. I would then customize the SES interceptor to look to see if the rc variable exists and is set to true and if so, bypass the check the SES interceptor does to see if the method is valid for the route. I’m sure I would bump into problems with this and I’m not wild about tweaking the SES interceptor anyways.
Of course I could always just add the OPTIONS action to each of my routes explicitly, but I’m a programmer and therefore lazy. Though at this point I probably should have just sucked it up.
Thanks in advance.
Brett
