session variables - application.cfm and multiple servers

[Dave]

You'll want to use client variables in a database rather than session or
application variables. Just make sure both machines can see the db
server.

[Seajay]

There are a number of possible things I can think of, but it depends on how you are set up - are both your CF web servers able to access the same database?

If so you could do something like create a 'shared key' field in the database when they authenticate to the 'insecure' server - (e.g. this could be a hashed uuid, which gives you a 32 character string - essentially random sequence,
e.g. <cfset myKey=hash(createUUID())>

This could then be included in the URL on your non-secure server for the user:

<a href="https://mysecureserve.com/securelogin.cfm?myKey=2C3FED62891AFE2342DE123373712917">connect to secure site</a>

and in the database store 2C3FED62891AFE2342DE123373712917 against the user id. Then when the user clicks the link, your secure server looks up the key in the database to see which user is accessing it and proceeds as if they had logged in with a username/password without having to have them retype usernames/passwords.

You will still need some code on the secure server to deal with this authentication and to set up variables etc as if they had logged in manually, but it does make the process invisible to the user. Alternatively you could use a table in the database to store shared variables, perhaps using CFWDDX to serialise them prior to storage in a text field.

[jrpugh]

Seajay...

Thanks for your suggestions, but I think I came up with a different approach. I am going to open a
new window on the secure server, passing via URL the link. The template itself will reside in my general
directory which doesn't execute the requied login and authentication script.

Calling the page with a valid URL variable will cause the system to error. I do like the idea of calling the page
with a UUID to validate against the user database when the page is called. This can then also check
to ensure the user who has accessed the page with the UUID has the access level required. I can
create and store the UUID at login since the user must login and authenticate in order to access the admin
menu choices. The UUID is a key element to this strategy because if by some chance someone randomly
entered a request id with the correct variable name into the URL for the page outside the admin directory
they could potentially access the page. To go one step even further, I can clear the UUID field in the database
when the user logs out, or their session ends.

What do you think about when the page is called, asking the user to verify their password as a cross check
against some monster trying to hack the security? This is the only way I can see to prevent random scans
against the UUID field in the table with the request id. As far as the user is concerned they will only notice
a cross check on their password, having them to enter it on entry to the page.

Thanks for your input.

Jim

If you make a lot of mistakes you are working... if you never make mistakes, you probably never work!