re[2]: [ACFUG Discuss] cross domain cookie validation

[Mischa Uppelschoten]

: Hey Mischa, :    : Thanks for the response.  I just got off the phone with the client trying to :  get a clearer description of what he is trying to do.  Originally the two :  applicationswere supposed to reside on the same server in the same domain.  :  Now the existing CF application will reside on www.domain1.com and the DLL :  they want to use to validate the login will reside on www.domain2.com.  So :  what he wants the CF app to do is submitthe login from www.domain1.com to a :  DLL on www.domain2.com to validate login, then write cookies from the members :  table containing customer info and then redirect back to www.domain1.com (CF :  app) and log them into that app.  For some reason (he cited hisclients :  security) he does not want CF to talk directly to the db on www.domain2.com :  to do the login itself, but rather submit to an existing DLL to validate the :  login, set cookies and the redirect back to CF. :    : Does that make sense? Kinda sorta. As far as using the authentication logic on the other domain: either that webserver needs to allow http access to that dll, or you have to use a DCOM or .NET call to access it directly. The first method is probably easier.   I'm puzzled what you mean by "then write cookies from the members table containing customer info". Cookies can only hold 4000 some characters, so they are really only suited for identification purposes, not for holding data.   You say "redirect back". I think you need to determine whether you want the CF server to go out to domain2, or the client. If you are going to be using cfhttp to let the CF server do it, there would be no need to "redirect back" since the user never leaves domain1. If you're letting the client (browser) do it, you'll need some sort of token from the client that proves that he or she got authenticated. To do that is not difficult, to do it right is over my head ;-).   If it were up to me, I would have the user come to domain1, submit credentials to CF, have CF go out to domain2, make sure the credentials are valid and start a CF session. Then, based on needs, have CF again contact domain2 with the credentials, request data and logoff (if applicable). The last part is where it gets a bit hairy: if that DLL sets up it's own session and tracks that using a cookie, then, in my scenario, the CF server will become the logged on client. The cookie, issued by domain2 will be stored somewhere on the CF server. This should all work, until user#2 comes around and logs in. The cookie on the CF server gets overwritten and now the users may see eachothers data.   I hope your client realizes that the architecture was just made a whole lot more complex :-( /m   (One other avenue would be to load the DLL on the CF server...) ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------