AngularJS, Coldfusion, and Security - forgive me, it's a little off-topic

[Jonathan Price]

As I mention in the title, this is probably off-topic for the group.  I'm posting in a few places in hopes of expanding my understanding, and I feel like there's a good chance someone here has some experience that's pertinent.  Hopefully, it's not bothersome.

The company I work for is building an application in which security is of the utmost importance.  We're really hoping to use Angular as the client-side for the application, and we're exploring how best to create our backend in ColdFusion.

I understand that only so much security can exist in the front-end of the application, and that the bulk of the work needs to happen on the server.  But I'm really unsure about how to move forward in that regard.  From what I've read, it sounds like we'll need some kind of Authentication Token to be created on login and stored on the backend.  This token should come along with every http request, and the server can then decide on the validity of the request.

Does this sound about right?  And if so, are there best practices for implementing it?

Also, any resources that might shed more light on the topic would be hugely appreciated.

Again, I apologize if this is too off-topic. You guys have just been so helpful in the past, so I figured I'd give it a shot.

Thanks,
Jonathan

[Jordan Michaels]

Are you completely separating your front-end (html, css, js) from your
CFML? Like, are you only interfacing with your CFML by way of API calls
from Angular? If not, then there's no reason not to stick with
tried-and-true cookie-based sessions.

It's only when you're separating out your front-end from your back-end
and interfacing with your back-end via API calls that you need to worry
about tokens - like if you're developing a mobile app that's designed to
run native instead of in a browser. With responsive web design, it's
possible to create an app using technologies you're already familiar
with that folks can simply run in their browser.

If you have your heart set on separating the front-end from the
back-end, I've been looking at auth systems recently as well and I like
the Java-based Nimbus JSON Web Token (JWT) libraries:

http://connect2id.com/products/nimbus-jose-jwt

They are OSS and free under the Apache 2 license.

On the Angular side of things, there's JSJWS:

http://kjur.github.io/jsjws/

Using these two libraries, you could have both your Angular App and your
API communicating using fully encrypted JWT's. Not that it would be
easy... but it would be possible! ;)

Warm Regards,
Jordan Michaels

> --
> --
> FW/1 on RIAForge: http://fw1.riaforge.org/
>
> FW/1 on github: http://github.com/framework-one/fw1
>
> FW/1 on Google Groups: http://groups.google.com/group/framework-one
> ---
> You received this message because you are subscribed to the Google
> Groups "framework-one" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to framework-on...@googlegroups.com
> <mailto:framework-on...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Sean Corfield]

And also...

If you're planning a completely REST-based backend - with CFML generating no views at all - then you might look at Taffy instead of FW/1 since you won't need a lot of FW/1 stuff and Taffy is designed for pure REST APIs (it was inspired by FW/1 in the first place and supports DI/1 nicely, I believe).

Sean

[denstar]

Along the "separate" lines (which I actually like), this one has been a
lot of fun:

http://keycloak.jboss.org/

There are examples for angular, etc., as well. Nice to be able to fire
it up in a openshift container (great stuff!) and whatnot. I'll
eventually package what I have up into some demos, it's pretty cool.

:Denny

[Puritan Paul]

You guys are the best.

Yes, we’re hoping to completely separate front and back end concerns, so the JWT stuff looks very compelling. i believe someone on the Angular board just suggested the same thing. Thanks for the references!

Taffy is very appealing, especially if it plays nice with DI/1, which we’re using now. However, I have zero experience with REST, so I’m not sure if we’ll initially implement the back-end as a RESTful service.

> To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.

[Puritan Paul]

I’d love to see your demos!

> On Nov 21, 2014, at 2:07 PM, denstar <vallia...@gmail.com> wrote:
>

> To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.

[Puritan Paul]

I’m realizing there’s a severe knowledge gap for me with this. Previously, we’d use session data to validate user requests, but with this new, separated front/back end I’m a little unclear about a few things. My plan was to, upon login validation, create a token and store it within the DB with the user’s ID. Future requests will be validated based on this combination.

1) Is this about right? How do we prevent a malicious user from accessing that key and using it for their own purposes? These requests will be over https, but is that enough?

2) How do I know when to expire this key? Now that we can’t depend on session expiration, I’m really unsure about what to do. Just increment the expiration date every time a request comes in with a given key? If that’s the case, I guess I’d need a scheduled task to run regularly and invalidate keys?

Feeling a little in over my head...

> On Nov 21, 2014, at 1:47 PM, Jordan Michaels <jor...@viviotech.net> wrote:
>

> To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.

[Richard Tugwell]

I use FW/1 controller APIs for client-side requests (eg Angular, or plain old jQuery). Because these are just normal FW/1 calls all my FW1 authorisation and authentication controls work just fine based on sessions.The only real difference between the API and normal FW1 controllers is that the methods return JSON as opposed to views. (NB I still have standard controllers returning views so Taffy isn't an option in my case as Sean suggested in another post). 

--

=================================
Richard Tugwell
http://blog.richardtugwell.com
r.tu...@forthmedia.com

[Andrew Myers]

It's a good question and one I'm interested in also.

We have a Java web app that uses Spring Security OAuth 2 to manage this, and it's absolutely awful to maintain. 

But it sounds like you want something that provides similar functionality.

Is there anything in CF that provides an OAuth server?  All I've come across are just client libraries.

>> an email to framework-one+unsubscribe@googlegroups.com
>> <mailto:framework-one+unsub...@googlegroups.com>.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> FW/1 on RIAForge: http://fw1.riaforge.org/
>
> FW/1 on github: http://github.com/framework-one/fw1
>
> FW/1 on Google Groups: http://groups.google.com/group/framework-one
> --- You received this message because you are subscribed to the Google Groups "framework-one" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to framework-one+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
--
FW/1 on RIAForge: http://fw1.riaforge.org/

FW/1 on github: http://github.com/framework-one/fw1

FW/1 on Google Groups: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.

To unsubscribe from this group and stop receiving emails from it, send an email to framework-one+unsubscribe@googlegroups.com.

[Sean Corfield]

For a secure API, you pretty much have to handle session management
yourself, with a DB table and some sort of unique token (e.g., UUID).

What we do at World SIngles is to use FW/1 for the REST portion so we
can leverage setupRequest() / before() / after() etc and organize our
app with controllers for sections of the API. We have three different
ways to login, each of those performs validation and then sets up a
token-based session and returns the token. All other requests must get
a token as an argument, and the FW/1 lifecycle methods can ensure the
request is authenticated (via the token).

So even in a pure REST world, FW/1 is still very valuable to us.

Sean

>> >> an email to framework-on...@googlegroups.com
>> >> <mailto:framework-on...@googlegroups.com>.

>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > --
>> > FW/1 on RIAForge: http://fw1.riaforge.org/
>> >
>> > FW/1 on github: http://github.com/framework-one/fw1
>> >
>> > FW/1 on Google Groups: http://groups.google.com/group/framework-one
>> > --- You received this message because you are subscribed to the Google
>> > Groups "framework-one" group.
>> > To unsubscribe from this group and stop receiving emails from it, send

>> > an email to framework-on...@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> --
>> FW/1 on RIAForge: http://fw1.riaforge.org/
>>
>> FW/1 on github: http://github.com/framework-one/fw1
>>
>> FW/1 on Google Groups: http://groups.google.com/group/framework-one
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "framework-one" group.
>> To unsubscribe from this group and stop receiving emails from it, send an

>> email to framework-on...@googlegroups.com.

>> For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> FW/1 on RIAForge: http://fw1.riaforge.org/
>
> FW/1 on github: http://github.com/framework-one/fw1
>
> FW/1 on Google Groups: http://groups.google.com/group/framework-one
> ---
> You received this message because you are subscribed to the Google Groups
> "framework-one" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to framework-on...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.



--

Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Richard Tugwell]

I suppose when I said API I just meant XHR requests within the same FW1application - I thought that was what Jonathan's use case implied.

[Puritan Paul]

Is your front end a single-page app?  There’s a pretty serious knowledge gap here for me - I don’t really understand how FW/1 is going to manage session data for you if it’s not building the pages?  If this truly works, man, it would be the quickest solution for me.

[Puritan Paul]

Your description basically sounds like exactly what I need to head towards. I’d considered FW/1 yesterday for the setupRequest functionality you mention - that seems very handy.

Can you expand on 'sets up a token-based session’? Is this just an entry into the DB (UUID, UserID, ExpirationDate, etc.), or is there more to it?

[Sean Corfield]

On Nov 25, 2014, at 12:39 PM, Puritan Paul <purit...@gmail.com> wrote:
> Can you expand on 'sets up a token-based session’? Is this just an entry into the DB (UUID, UserID, ExpirationDate, etc.), or is there more to it?

We record UUID, userId, lastVisitTimeStamp. We update lastVisitTimeStamp on each request - that's key to keep "sessions" alive. We start the "session" when the user is identified (authenticated) and that's when we create the UUID.

We have logic to scavenge the table for "timed out" sessions, i.e., lastVisitTimeStamp is older than some arbitrary idle timeout (I think we use 40 minutes).

Whilst you can use session scope for an AngularJS app since it will send a session ID cookie on each request, I'd recommend trying to keep your app stateless so you'll be able to use the API-based back end for other services (e.g., a true server-to-server API, or a native mobile app, or...).

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

[Puritan Paul]

Great, this sounds perfect. I’m proofing a native mobile app right now using phone gap, so the stateless bit is key. Thanks for the insight.

[Puritan Paul]

Okay, so based on this thread and suggestions from Sean in another thread, I’m going to re-institute FW/1 as part of the back-end process, but I’m going to handle sessions myself.

Having said that - I’m thinking I’ll do something like you’d suggested, Richard, with controllers functioning as my interface objects.  So, my http calls in angular would reference something like

index.cfm?action=user.login,  or  index.cfm?action=patient.getInfo

And in those particular functions, I can use the renderData function to bypass FW/1 view stuff.  Right? Does that more or less make sense?  I’m certainly open to suggestions.

My plan is to eventually port the API to be a REST API, but we’re on a pretty steep timeline right now, and I can’t shoulder that much change just yet.

———

As a side note, I just tried this, and I’m getting a 'The renderData method was not found.’ error?  My Application.cfc has this:  <cfcomponent extends="lib.framework”> up top, so I’m not sure what gives.  My other fw/1 apps have basically the same Application.cfc file, and I can’t recall having this problem in the past.

———

And again, thanks for the input, everyone!  It’s been a big help.

Jonathan

[Sean Corfield]

On Nov 25, 2014, at 6:02 PM, Puritan Paul <purit...@gmail.com> wrote:

index.cfm?action=user.login,  or  index.cfm?action=patient.getInfo

I’d recommend using SES URLs or routes, you can use

/user/login or /patient/getinfo

or just:

/login or /patientinfo

And in those particular functions, I can use the renderData function to bypass FW/1 view stuff.  Right?

Yes, that’s what we do at World Singles:

variables.fw.renderData("json",someStructure);

As a side note, I just tried this, and I’m getting a 'The renderData method was not found.’ error?

Your controller needs:

property framework;

and then use:

variables.framework.renderData(…);

Or have an init() method in your controller:

function init( fw ) {

variables.fw = fw;

return this;

}

and then use:

variables.fw.renderData(…);

[Puritan Paul]

Ah, brilliant, the SES URLs are much more attractive.  And my old controllers didn’t have the ‘variables.fw = fw’ bit in their init functions - but they were working.  Weird, but not important.

So, I’ll have two functions that should probably run every request, i think:  1) validate token and get current user based on that token 2) verify that the user is allow to access whatever section.item they’re trying to access.

I’m unsure about how to handle things like this in the setupRequest() or the controller before() calls.  I understand why you put them there, but I don’t understand how you handle errors.  Say, the token doesn’t validate - how do I break out of the cycle and return an error?   Just cfreturn?  

In other words, I see this in the documentation:

function setupRequest() {
  controller( 'security.checkAuthorization' );
}

But I’m unclear on what happens if the security.checkAuthorization call fails?

Tangentially, are you supposed to use local scope for variables that you don’t want assigned to the rc within controllers and services?

[Sean Corfield]

On Nov 25, 2014, at 10:30 PM, Puritan Paul <purit...@gmail.com> wrote:
> So, I’ll have two functions that should probably run every request, i think: 1) validate token and get current user based on that token 2) verify that the user is allow to access whatever section.item they’re trying to access.
>
> I’m unsure about how to handle things like this in the setupRequest() or the controller before() calls.

What I recommend is something like this:

function setupRequest() {
header name="Access-Control-Allow-Origin" value="*";
controller( "security.validate" );
}

And then controllers/security.cfc's validate() would look something like this:

function validate( rc ) {
// if no valid token, and not exempt route => unauthorized
var userId = structKeyExists( rc, "securetoken" )
? variables.securityService.lookupUserByToken( rc.securetoken )
: 0;
if ( userId ) {
rc.user = variables.userService.get( userId );
variables.sessionService.ping( userId );
} else {
if ( !exemptRoute( rc.action ) ) {
specialResult( 401, "Unauthorized Access" );
}
}
}

where exemptRoute() returns true if rc.action does not need security (e.g., it's the login action) and specialResult() looks a bit like this:

function specialResult( status, reason ) {
// used to return compound data with non-200 status
header statusCode="#status#" statusText="#reason#";
variables.fw.renderData( "json", { "fail" : reason }, status );
variables.fw.abortController();

}

> I understand why you put them there, but I don’t understand how you handle errors. Say, the token doesn’t validate - how do I break out of the cycle and return an error? Just cfreturn?

I use specialResult() for most errors (so a 200 status is reported only for successful requests; erroneous requests get a 400-series status), and then in my main controller, I have this error() function:

function error( rc ) {
var response = { "fail" = "An error occurred", "reason" = request.exception.message };
variables.fw.renderData( "json", response, 403 );
}

which is how FW/1 handles exceptions. This gives a Forbidden result for requests that failed.

> Tangentially, are you supposed to use local scope for variables that you don’t want assigned to the rc within controllers and services?

Yes, declare variables with 'var' to ensure they are thread safe.

[Puritan Paul]

This is great. I’d started something similar to this, I just couldn’t figure out the abortController part!

I’m not very familiar with the ins and outs of http header elements, so thank you for putting the 'Access-Control-Allow-Origin’ bit in there. Had no idea about that, and now I’m reading the Cross Origin docs on mozilla. Thanks!

[Puritan Paul]

Forgot! Is the ping(userId) bit where you're updating session expiration?

[Sean Corfield]

On Nov 26, 2014, at 7:27 PM, Puritan Paul <purit...@gmail.com> wrote:
> Forgot! Is the ping(userId) bit where you're updating session expiration?

Yes.

[Puritan Paul]

In the process of implementing this security stuff, I’ve managed to botch up injection somehow. I’m getting a 'Element SESSIONSERVICE is undefined in….’ error, and I’m not sure why. I commented out everything in the setupRequest function thinking that might be it, but alas. The login API function being called looks more or less like this:

<cfcomponent accessors="true" displayname="User”>

<cfproperty name="sessionService”>

<cffunction name="login" access="remote" returntype="ANY" output="false" returnformat="JSON">
<cfargument name="rc" type="struct" required="true">

<cfset LOCAL.login = variables.sessionService.loginUser(username = "#rc.username#", password = "#rc.password#”)>
…



And the sessionService line is what’s throwing the error. Not much going on, and everything was working great last night. Obviously, I’m missing something.

I think I’ve had similar issues in the past where I can’t figure out why injection has stopped working. Are there good methods for hunting this kind of error down?

Also, if I call API functions from the browser URL, should I expect injection to continue working? I’m guessing not, right?

[Sean Corfield]

On Nov 27, 2014, at 3:08 PM, Puritan Paul <purit...@gmail.com> wrote:
> In the process of implementing this security stuff, I’ve managed to botch up injection somehow. I’m getting a 'Element SESSIONSERVICE is undefined in….’ error, and I’m not sure why. I commented out everything in the setupRequest function thinking that might be it, but alas. The login API function being called looks more or less like this:

How are you invoking the login() handler? It has to be via FW/1's normal request lifecycle for the frameworks to do their job.

> Also, if I call API functions from the browser URL, should I expect injection to continue working? I’m guessing not, right?

No, as I said before, you've got to go through the framework's normal request lifecycle for this sort of thing to work.

[Puritan Paul]

Right.  My angular http call is directly addressing login() - it lives in /webroot/controllers/user.cfc.   Login, then calls a few services to make things happen.

It sounds like this shouldn’t have worked at all since I’m addressing it directly?  I think that’s why I’m confused - that it was working to begin with.

Regardless - my api controllers should use the getBean function to wire their own dependencies in, right?  Wiring should work for the services it calls though, correct?

Ultimately, I guess I’m just not clear about what constitutes a normal request lifecycle.  As in, how/why is calling a controller directly different that a standard use case?

[Puritan Paul]

FWIW, I changed my login function back to this:

    <cffunction name="login" access="remote" returntype="ANY" output="false" returnformat="JSON">

        <cfargument name="rc" type="struct" required="true">

        <cfset LOCAL.sessionSvc = APPLICATION.beanFactory.getBean( "sessionService" )>

        <cfset LOCAL.login = LOCAL.sessionSvc.loginUser(username = "#rc.username#", password = "#rc.password#”)>

And I’m getting a 'bean not found: sessionService’ error now.  So, maybe something more is afoot?

 

[Sean Corfield]

On Nov 27, 2014, at 3:32 PM, Puritan Paul <purit...@gmail.com> wrote:

Right.  My angular http call is directly addressing login() - it lives in /webroot/controllers/user.cfc.   Login, then calls a few services to make things happen.

You cannot do that. You *must* go through FW/1.

You can request /user/login - as a FW/1 SES URL that invokes the controller method through the normal FW/1 request lifecycle

Regardless - my api controllers should use the getBean function to wire their own dependencies in, right?

No, not if you’re using FW/1. Controllers can just declare property dependencies and it will work.

Wiring should work for the services it calls though, correct?

Yes, if you’re going through FW/1 because either FW/1 will ask DI/1 for the controller - which will fully wire in the dependencies - or FW/1 will create the controller and ask DI/1 for the dependencies.

Ultimately, I guess I’m just not clear about what constitutes a normal request lifecycle.  As in, how/why is calling a controller directly different that a standard use case?

If you call the controller via the URL, FW/1 is not involved in the request at all.

You are really making a lot of work for yourself (and us!) by not just doing things the normal FW/1 way. All this pain is because you are fighting the framework instead of letting it do the work for you.

[Sean Corfield]

See my other response.

Unless you start using FW/1 and stop trying to work around the framework, there is no point in you asking further questions here and no point in us trying to help you.

We’ve told you what to do and you’re just ignoring us - and then of course your code won’t work.

Sean

[Richard Tugwell]

Paul

It doesn't satisfy your questions about server-to-server API's, but have a look at this

https://github.com/framework-one/fw1/tree/develop/examples/todos

It's a very simple angular/FW1 app that illustrates calling controller methods via angular and invoking services - might give you some pointers. 

--
--
FW/1 on RIAForge: http://fw1.riaforge.org/
 
FW/1 on github: http://github.com/framework-one/fw1
 
FW/1 on Google Groups: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puritan Paul]

Oh man, I’m super confused.  I thought I was following your instructions.

I think I might have misspoke when I said my angular http call is directly addressing login().  My angular API service looks like this:

        function getBackendBase() {

            return 'backend/index.cfm'

        }

        return {

            login: function(credentials) {

                // initialize logged in user.  Currently assumed we're already logged in.

                return $http({

                    method: "post",

                    url: getBackendBase() + "/user/login",

                    data: $.param({

                        username: credentials.username,

                        password: credentials.password

                    }),

                    headers: {

                        'Content-Type': 'application/x-www-form-urlencoded'

                    }

                })

            }

}

Which I thought was the correct fw/1 way.  

My coldfusion API object is a controller at /webroot/backend/controllers/user.cfc

My Application file is under /webroot/backend

The User.cfc looks like:

<cfcomponent accessors="true" displayname="User”>

    <cfproperty name="sessionService">

    <cffunction name="init" access="public" output="no">

        <cfargument name="fw">

        <cfset variables.fw = fw>

        <cfreturn this>

    </cffunction>

    <cffunction name="login" access="remote" returntype="ANY" output="false" returnformat="JSON">

        <cfargument name="rc" type="struct" required="true">

        <cfset LOCAL.login = variables.sessionService.loginUser(username = "#rc.username#", password = "#rc.password#")>

…….this is the Entity not found error ……

---

So, where is my misstep?  I’m sorry if you’ve already explained it to me - I’ve re-read all my emails a few times now, I’m still at a loss.  I genuinely thought I’d been following your instructions up to now.

Again, I’m sorry to be a bother.

[Sean Corfield]

Show us your Application.cfc.

BTW, you went through almost this exact same thing back in August with a number of posts where you were having very similar problems - so maybe just look through the list archives for August for your own threads and the answers people gave you then.

[Puritan Paul]

I looked through the old emails.  Will double check now.

-----

Application.cfc:

<cfcomponent extends="lib.framework" accessors="true">

<cfscript>

variables.framework = {

   trace = false

};

</cfscript>

<cfset THIS.datasource = "xmdlocaldevdb">

<cfset THIS.name = "XMD_Mobile_LOCAL">

<cfset THIS.ormsettings.cfclocation = "/xmdmroot/backend/model/beans">

<cfset THIS.baseDirectory = "/xmdmroot">

<cffunction name="setupApplication">

<cfscript>

       APPLICATION.beanFactory = new lib.ioc("/xmdmroot/backend/model"); 

       setBeanFactory(APPLICATION.beanFactory);

   </cfscript>

</cffunction>

<cffunction name="setupRequest"> 

<!--- <cfset REQUEST.dsn = THIS.datasource> --->

<!--- <cfheader name="Access-Control-Allow-Origin" value="*" /> --->

<!--- <cfset controller( 'authorization.validate' )> --->

    </cffunction>

</cfcomponent>

[Sean Corfield]

On Nov 27, 2014, at 5:56 PM, Puritan Paul <purit...@gmail.com> wrote:

variables.framework = {

   trace = false

};

And which version of FW/1 are you using?

If you’re using 3.0, FW/1 will try to use DI/1 automatically for you, to manage controllers and model. You either need to let it do its thing (and remove your setupApplication() function) or tell it not to use a diEngine internally (set diEngine = "none" in the framework config).

If you’re using 2.5 or earlier, you’re fine the way you are (but bear the above in mind if you are migrating to 3.0).

On Nov 27, 2014, at 5:44 PM, Puritan Paul <purit...@gmail.com> wrote:

Oh man, I’m super confused.  I thought I was following your instructions.

...

                    method: "post",

                    url: getBackendBase() + "/user/login",

OK, this is going through FW/1. You said you were accessing login() directly - which you are not.

My coldfusion API object is a controller at /webroot/backend/controllers/user.cfc

/webroot/backend/controllers or /xmdmroot/backend/controllers?

So, where is my misstep?

At this point, I’m not sure.

Where are you service CFCs? In particularly, what is the session service CFC called and where exactly is it?

[Puritan Paul]

On Nov 27, 2014, at 6:52 PM, Sean Corfield <se...@corfield.org> wrote:

On Nov 27, 2014, at 5:56 PM, Puritan Paul <purit...@gmail.com> wrote:

variables.framework = {

   trace = false

};

And which version of FW/1 are you using?

I’m on 2.2_rc2

If you’re using 3.0, FW/1 will try to use DI/1 automatically for you, to manage controllers and model. You either need to let it do its thing (and remove your setupApplication() function) or tell it not to use a diEngine internally (set diEngine = "none" in the framework config).

If you’re using 2.5 or earlier, you’re fine the way you are (but bear the above in mind if you are migrating to 3.0).

On Nov 27, 2014, at 5:44 PM, Puritan Paul <purit...@gmail.com> wrote:

Oh man, I’m super confused.  I thought I was following your instructions.

...

                    method: "post",

                    url: getBackendBase() + "/user/login",

OK, this is going through FW/1. You said you were accessing login() directly - which you are not.

Yeah, sorry about that.  Pretty contentious point to mis-communicate.

My coldfusion API object is a controller at /webroot/backend/controllers/user.cfc

/webroot/backend/controllers or /xmdmroot/backend/controllers?

/xmdmroot  is the mapping I’m using.

So, where is my misstep?

At this point, I’m not sure.

Where are you service CFCs? In particularly, what is the session service CFC called and where exactly is it?

session.cfc is under model/services.

Out of frustration I cleared out the entire backend dir and started to piecemeal it back together.  It looks like the problem was this line:

        APPLICATION.beanFactory = new lib.ioc("/xmdmroot/backend/model"); 

I made it a relative path instead (“/model”), and it looks like the injection is working now.  I dunno, though.  I feel like I made that change yesterday at some point when things were working.  I’ll keep putting it back together till I hit another wall.

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Puritan Paul]

Ugh.  So appearantly the mapping got updated, leaving DI/1 to pull from a non-existent directory.  What a frustrating waste of time.  Sorry, everyone.

[Sean Corfield]

Glad you got to the bottom of it.