Exclude the web root

[Tom Chiverton]

I'm trying to add a Taffy API to an existing site.
I want to share session between the API and the main CFML application to save having to build an API login infrastructure.
This means the Application.cfc that extends Taffy is in the main webroot.
The trouble is, Taffy keeps intercepting requests for other CFML files in the web root e.g. '/login.cfm'.

Specifying '/' in the unhandledPaths doesn't help.

if I have a return of true in isUnhandledRequest by CFML in the web root is processed, so I was thinking of putting some special case code in there for when the unhandledPath contains '/' and the file is in the root ?

Is this a good plan (that would likely be merged) ? Is there a better way ? Is there a ready made HMAC-type login framework I should be using that would be quick to implement with Angular ?

Tom

[Adam Tuttle]

Hi Tom,

I'm curious exactly why you want to put your Taffy Application.cfc into the webroot. If your Resource URIs end up being something like /api/v1/foo then why not just put Application.cfc into the /api/v1/ folder and make your Resource URIs /foo (which are relative to Application.cfc, so still functionally /api/v1/foo)?

At this time there are no plans to work on the unhandled paths exclusions engine... but that doesn't mean pull requests around it will be shunned. Your idea of adding more logic to isUnhandledPathRequest sounds reasonable, just be sure not to break any existing functionality by running the unit tests before and after you make your changes!

I'm not aware of any existing HMAC library/framework code that people are pairing with Angular, but I know that there are multiple people using Angular with Taffy, so hopefully someone else can jump in and offer some advice there?

Adam

--
You received this message because you are subscribed to the Google Groups "Taffy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taffy-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Chiverton]

On Thursday, June 25, 2015 at 3:01:46 PM UTC+1, Adam Tuttle wrote:

Hi Tom,

I'm curious exactly why you want to put your Taffy Application.cfc into the webroot. If your Resource URIs end up being something like /api/v1/foo then why not just put Application.cfc into the /api/v1/ folder and make your Resource URIs /foo (which are relative to Application.cfc, so still functionally /api/v1/foo)?

Maybe a diagram will help.
I need to have the user sessions visible in both the API and the app, so a file layout like :

/Application.cfc
/api/taffy
/api/resources
/api/Managers
/website/index.cfm
/index.cfm

and then when someone is logged in by the code in the root (and redirected into '/website/' I can get at them from Taffy managed CFCs in /api/ when Angular makes a request.

At this time there are no plans to work on the unhandled paths exclusions engine... but that doesn't mean pull requests around it will be shunned. Your idea of adding more logic to isUnhandledPathRequest sounds reasonable, just be sure not to break any existing functionality by running the unit tests before and after you make your changes!

https://github.com/tomchiverton/Taffy/pull/1 is where I'm with it at the moment.
I've not run all the tests, but it lets us say
"
        unhandledPaths="/website,/"
"
in the Taffy config, where as before that would cause Taffy to break because the regular expression for '/' matches '/api'.

But I am wondering why Taffy is written to suck up all requests except some, rather than only processing requests in a particular path e.g.
"
        handledPaths="/api"
"
which must be more common ?

Tom

[Adam Tuttle]

That aspect of Taffy is modeled very much after FW/1, which behaves the same way: all requests in the application use the application's routing regardless of what file the url is requesting (tom.cfm vs index.cfm vs whatever...)

I'm not going to browbeat you with it, but I will throw this out there: Sessions are a REST API anti-pattern. There's a good chance there's a better way (e.g. more scalable, more stateless) to accomplish what you want to do with your sessions. If you want to share what the exact goal is for using sessions in your API, we can discuss that further. :)

At any rate, you can share session scope between two CF applications pretty easily even if they have two totally different URL paths. Just give them the same application name. This does mean that both applications need to be capable of setting up everything that belongs in application scope (or at least smart enough to setup everything that it needs for itself even if the application was previously started in the "other" application in a prior request)...

--

[Tom Chiverton]

On Thursday, June 25, 2015 at 4:28:55 PM UTC+1, Adam Tuttle wrote

good chance there's a better way (e.g. more scalable, more stateless) to accomplish what you want to do with your sessions. If you want to share what the exact goal is for using sessions in your API, we can discuss that further. :)

Always happy to hear what others think, and I totally get that you aren't meant to use sessions in APIs

It's related to why I asked about HMAC-type signed requests.
Think of the app as a per-user address book, so when the API receives a "GET /api/addressbook" it needs to know the logged in user. If session's are shared, then the resource can lookup session.userId and pass that into the manager for the query.

I'd considered instead, that wasn't as much work as full API-request signing, having the /api/ folder protected with HTTP Basic (it is over SSL). But we can't have the client send the username (anyone could impersonate anyone else then). So it ends up being as complex as signed requests.Unless there is an easy way to store the entered password from the login screen that doesn't leave it in plain text in the client ? Note sure there is...

We could also have the client call a 'login' api to get a token that it must present as part of all future requests, but that's a bunch of work to store, expire etc as well.

 

both applications need to be capable of setting up everything that belongs in application scope (or at least smart enough to setup everything that it needs for itself even if the application was previously started in the "other" application in a prior request)...

This is exactly the problem I'm avoiding by sticking both the api and webroot under a single Application.cfc :-)

[Adam Tuttle]

On Thu, Jun 25, 2015 at 12:19 PM Tom Chiverton <tom.ch...@gmail.com> wrote:

On Thursday, June 25, 2015 at 4:28:55 PM UTC+1, Adam Tuttle wrote

good chance there's a better way (e.g. more scalable, more stateless) to accomplish what you want to do with your sessions. If you want to share what the exact goal is for using sessions in your API, we can discuss that further. :)

Always happy to hear what others think, and I totally get that you aren't meant to use sessions in APIs

It's related to why I asked about HMAC-type signed requests.
Think of the app as a per-user address book, so when the API receives a "GET /api/addressbook" it needs to know the logged in user. If session's are shared, then the resource can lookup session.userId and pass that into the manager for the query.

I'd considered instead, that wasn't as much work as full API-request signing, having the /api/ folder protected with HTTP Basic (it is over SSL). But we can't have the client send the username (anyone could impersonate anyone else then). So it ends up being as complex as signed requests.Unless there is an easy way to store the entered password from the login screen that doesn't leave it in plain text in the client ? Note sure there is...

We could also have the client call a 'login' api to get a token that it must present as part of all future requests, but that's a bunch of work to store, expire etc as well.

When the user logs in, you could drop an api key that identifies them into the page (assuming a single page app?) as a JS variable or throw it into localStorage or something, and that would identify their API requests.

Alternatively, you could NOT do server-side login, and instead do that over your API. Then on successful auth return an api key that expires in some reasonable amount of time; forcing them to re-auth.

It all depends on how secure you need to be. :) 

both applications need to be capable of setting up everything that belongs in application scope (or at least smart enough to setup everything that it needs for itself even if the application was previously started in the "other" application in a prior request)...

This is exactly the problem I'm avoiding by sticking both the api and webroot under a single Application.cfc :-) 

Quite understandable!