Forum OpenACS Q&A: demo login package

Collapse
1: demo login package
Posted by Tilmann Singer on 02/17/02 01:02 AM
If you too have been annoyed too often by OpenACS presentations that were interrupted with "Now let's login as Peter to see that this item appears on his list ... what was his email and password again? ... no, that one was wrong ... ok, logged in - where was that page that I wanted to show you? ..." and so on, then check out my demo-login package at: https://openacs.org/new-file-storage/one-file.tcl?file_id=307

It features a list of demo user accounts with a "become this user" button next to each, lists the user's group memberships and optionally some demo account description. The accounts are selectable from existing user accounts by an admin.

It also contains a little template intended to be included at the footer of default-master.adp that alway displays the currently logged in username and a link to the demo-login instance.

If there's interest then I can polish it up a bit, add some documentation etc.

(It's OpenACS 4, currently postgresql only btw.)

Collapse
2: Response to demo login package (response to 1)
Posted by Stephen . on 02/17/02 10:35 PM
Have you seen the 'switch user' feature in the Developer Support package?
Collapse
3: Response to demo login package (response to 1)
Posted by Tilmann Singer on 02/18/02 08:24 PM
I haven't seen that yet - thanks for the hint. (I knew I had to check it out someday but then i forgot to)

Although the user-switch in developer-support is quite useful it does not provide some features that I needed and added to the demo-login package, so it is not a complete duplication of effort: first, demo-login allows for unattended demonstration installations where for some reasons you do not want to allow the tester to become site-wide admin or some other privileged user. Second - the ability to add some explaining text to each account, so that the testing user knows what the account is supposed to demonstrate. This is useful for demonstrations that include different users with very specific different roles, e.g. in a particular customization of a workflow.

Btw, I found a problem with the developer-support user switch: it replaces the two procs ad_get_user_id and ad_verify_and_get_user_id with it's own implementation, but not the behaviour of [ad_conn user_id], which is used quite often in the toolkit (and seems to be the preferred way since the both procs above are -deprecated).

A possible way to fix this would be to overload ad_conn in acs-developer-support-procs.tcl as well. Any better suggestions? (I've entered a bug in the sdm for that.)

Collapse
4: Response to demo login package (response to 1)
Posted by Lars Pind on 02/19/02 01:19 AM
Tilmann,

I was the original author of the user-switching feature, because I got fed up with logging in time and again while developing workflow. Without looking, I doubt that anybody have really spent much effort trying to keep it up-to-date, including me.

At the time it was developed, [ad_conn user_id] wasn't used. So indeed, one approach would be to overload that one, too. Or we could find a whole new way of doing things, by hacking into the procs parsing the cookies, or see if there's some other single spot that we can hack the user-identification chain for our purposes.

Hm. Rambling here. Haven't actually looked at the code.

Collapse
5: Response to demo login package (response to 1)
Posted by Stephen . on 02/19/02 03:49 AM
Developer Support doesn't work because it is packaged as an add-on. It requires extensive support from the request processor to work at all so there's no real utility having the interface in a seperate package.

The disadvantage is that no one is aware of the user switching functionality (it overides core procs, breaking the doumentaed behaviour...) so when things change, it breaks.

The reason I mention it is because your package is so useful, adds no overhead, and is unlikely to have many implementations, that I think it would be a shame to have a second seperate package to implement what really is core ACS functionality.

Collapse
6: Response to demo login package (response to 1)
Posted by Lars Pind on 02/19/02 01:12 PM
The reason that the developer-support user-switching thing was packaged separately was that it's so dangerous (can give access to other people's data) that you want to be able to make absolutely sure you're not running the code on a production site, by simply leaving the code out altogether.
Collapse
7: Response to demo login package (response to 1)
Posted by Stephen . on 02/19/02 02:01 PM
It seems a bit drastic to say that the only way we can restrict access to 'powerful' functions is by completely removing the code.  The user switching feature is disabled by default, and restricted by the permission system to admins. Besides, similar functionality is present within the acs-admin pages ('become this user'), restricted to admins. What's the difference?

I don't mean to labour the point, but the lack of integration within ACS is my pet peeve. The extensive duplication of 50% solutions makes it extremely difficult to understand and build upon.

Collapse
8: Response to demo login package (response to 1)
Posted by Tilmann Singer on 02/19/02 11:27 PM
Here's a patch to developer-support that makes the user switching work with packages that use [ad_conn user_id]: patch #153. It adds [ad_conn user_id] to the list of overloaded functions - just a quick fix until somebody comes up with a better solution.