You're approaching this in the wrong way, I think. Ideally what you'd
do is take your existing security mechanism (whatever it is) and add
the ability to "spoof" another user. So any Administrator could hit
the "I want to spoof" page where they'd see a list of Super Users to
pick from. When they pick you, manipulate your authentication store
(probably in session variables) to indicate that the person is really
still Administrator X, but the site should consider them to be Super
User Y. The same mechanism would hold for the Super User -> End User
pairing.
Here's a really simple example.
I'm going to assume you have something like this currently:
session.isAuthenticated (a boolean), session.userId (the identifier of
the user who is authenticated), and session.userType (one of
administrator, superUser, or endUser). When someone logs in, you do
your checks, and set those three variables. Then the site reads those
three variables in order to make decisions about what to render and
how.
In that case, you want to add session.baseUserId, and
session.baseUserType that are initialized to the same as userId and
userType on login, and which the site never read. Then somewhere add
code like this:
<cfif listFind("administrator,superuser", session.baseUserType) GT 0>
<cfif session.userId EQ session.baseUserId>
<!--- they can spoof, but they aren't currently --->
<a href="start_spoofing.cfm">start spoofing</a>
<cfelse>
<a href="stop_spoofing.cfm">stop spoofing</a>
</cfif>
</cfif>
Those two pages (start_spoofing.cfm and stop_spoofing.cfm) should take
care of setting/clearing session.userId and session.userType to allow
the user to spoof someone else, without touching their "real" session
state, which is stored in baseUserId and baseUserType.
Obviously that's a really generic description, but hopefully it'll get
you started down the right path. It overcomes a couple really
important shortcomings with what you proposed as well. Namely, you
don't have to render an arbitrary user's password out to other users
(which is REALLY bad), and you don't even have to have the passwords
in a readable format (which you really should never do). It also
keeps your users with some connection to their "real" user context,
even when they're emulating another user, so they can "back out" and
return to normal without logging out and having to log back in as
their normal user.
cheers,
barneyb
On Wed, Oct 21, 2009 at 3:56 PM, Asaf Peleg <a...@locusenergy.com> wrote:
>
> Hi everyone,
>
> My websites has different types of profiles that our end users log into that
> follows a simply hierarchy that goes as follows.
>
> Administrator -> Super Users -> End Users
>
> Where all Super Users are managed by the Administrator and each Super User
> manages a subset of all End Users. Each profile is locked by a username and
> password from a login page. For debugging, auditing or support purposes
> sometimes it becomes very useful for the Administrator to log into the
> profile of one of his Super Users or for a Super User to log into one of his
> End Users profiles since each profile contains different landing pages and
> content. I'm trying to achieve this functionality without the need to look
> up that persons password (for obvious security reasons) so I've been toying
> around with different methods.
>
> My first thought was to use CFHTTP but I've had no luck with it. I thought I
> could simply do
>
> <cfhttp url="mylogincheck" method="post" redirect="true">
> <cfhttpparam type="formfield" name="username" value="#username#">
> <cfhttpparam type="formfield" name="password" value="#password#">
> </cfhttp>
>
> and it would redirect me much like a <cflocation> does except with form data
> being posted, but I could get that desired behavior. I've gave up on this
> and did the following.
>
> <cfoutput>
> <form action="mylogincheck" method="post" name="login">
> <input type="hidden" name="username" value="#username#">
> <input type="hidden" name="password" value="#password#">
> <script language="JavaScript">
> document.login.submit();
> </script>
> </form>
> </cfoutput>
>
> Which works but I'm concerned this is a not the correct way and could
> possibly pose security issues since I'm technically creating an HTML page
> with someones password even though the page redirects instantly. Would anyone
> care to tell me what I'm doing wrong with <CFHTTP> or if alternatively, my
> concerns are unfounded and my solution is in fact secure.
>
> Thanks,
> Asaf
>
--
Barney Boisvert
bboisv...@gmail.com
http://www.barneyb.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Want to reach the ColdFusion community with something they want? Let them know
on the House of Fusion mailing lists
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:327482
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
