Forum OpenACS Development: How to do sessions

Posted by sal berg on

I had an extremely hard time trying to figure out how to extend the login and registration system for my needs, so I decided to roll my own (it was either that or move to another product). So this was my approach, which seems to be "working" (cough). You can look at it and give feedback before I ask my question.

1. Made my own "users" database table.
2. Added a test user to the table by hand.
3. Made a login screen (adp/tcl). The login screen simply does a database select on username/password and redirects to the "logged in" screen on success, or "error" screen on failure.

Look reasonable?

At any rate, now I would like sessions. If I had extended the openACS login/registration, I guess this would have been automatic, but that's not happening. Is this reasonably easy to do "by hand?" Can someone point me to resources (API calls and what not)?


2: Re: How to do sessions (response to 1)
Posted by Dave Bauer on
I think you should reconsider your plans.

There really isn't much benefit to using OpenACS without the users login and security system. By writing your own you can also introduce security issues that have been discovered and resolved over 10 years of use.

If you want to extend the information you collect on registration this should not be too hard. The first question is what version of OpenACS are you using. From there I can recommend the best solution.

If you want to understand how sessions work you should review under openacs-4/packages/acs-tcl/tcl/security-procs.tcl.

3: Re: How to do sessions (response to 2)
Posted by sal berg on
Yes, I need to extend the information I collect on registration, but I found figuring out how to do it (and other things) to be a nightmare. I guess you're right that there isn't too much benefit to using the system without the built-in login and security stuff - perhaps I should move on to something else?

The version I'm running is the latest version for Windows. I'm just using the Windows version for test and development. I planned on moving everything to unix for production.

4: Re: How to do sessions (response to 1)
Posted by Torben Brosten on
Hi Sal,

There's a few different ways to extend registration.

One low tech way is used by ecommerce, where registration is followed by a redirect to checkout.

There's also a way where you can create a user using the API directly.

I'm sure Dave will explain how to approach extending the registration page directly --I haven't done that, so can't help there.

ad_form is used for building dynamic forms. If you're like me and find that too abstract, having too many limitations, or requiring a high learning curve to be of value, then there's an alternate method which will soon be available that uses a tcl styled API to build forms. The learning curve for this new way is low, because it depends on knowing html forms and tcl, not much else. I am debugging/alpha testing it now and will post when it reaches beta.



5: Re: How to do sessions (response to 4)
Posted by sal berg on
Hi Torben,

I did make a form already using ad_form. Actually, I didn't find it *too* bad - documentation and a walk-through were readily available. Some things that weren't documented took some time to figure, but at least they were "reasonably figure-able." Still, better is always, well, better, so I look forward to seeing your new forms!

Hope Dave or somebody can help me out with the other stuff.


6: Re: How to do sessions (response to 5)
Posted by Dave Bauer on
The advantages to ad_form are consistent form behavior throughout an application, inline error reporting etc. There may be some newer technology we could use to rewrite this, but so far it has worked.

The question is if your acs-kernel is 5.6.0. You can check this by visiting the URL /acs-admin/apm/ under your installation and checking the version number for the acs-kernel package.

If this is the case, I am working on a tutorial for customizing a subsite that would be perfect to help you. If you are using a version older than 5.6.0 the techniques are different.

7: Re: How to do sessions (response to 6)
Posted by sal berg on
It's 5.6.0.
8: Re: How to do sessions (response to 7)
Posted by Dave Bauer on
In this case you want to create a new package that is a subtype of the acs-subsite package. Then you can place all of your customizations into your new package.

I am working on the tutorial for this, I'll see if I have something that will help you.

9: Re: How to do sessions (response to 1)
Posted by Andrew Piskorski on
Sal, if you can't understand how the current OpenACS user login and registration code works by reading and playing with it, then I have no idea how the hell you hope to write something better on your own. The current OpenACS code might not be a model of simplicity and clarity, but neither is it all that complicated. If you're actually good enough to write your own, you're more than good enough to read the OpenACS source, understand it, and figure out how to modify it to suit yourself.

I would go with the latter approach. Also, if for some reason I needed to write my own user tracking code complete with users table, etc. (e.g., for an entirely different system), I would certainly read the OpenACS code, make sure I understand why it's doing things, and then use it as a model.

10: Re: How to do sessions (response to 9)
Posted by sal berg on
I think you are right, Andrew. Despite having done software engineering for major companies such as IBM and others, I can't understand most anything about OpenACS. Oh, in truth, it isn't that I couldn't sit down and reverse engineer the system and understand it, given enough time and energy. It's that most sane people wouldn't want to put forth the effort to sit down and do that.

So you are right - I'm outta here. This is the last post I will bother you people with.

11: Re: How to do sessions (response to 10)
Posted by Andrew Piskorski on
Sal, that's ironic, as my personal experience is that the OpenACS codebase, particularly the Tcl layer, is fairly easy to modify. Are you sure you're not just hitting the old, "starting over from scratch seems like it would be more fun" programmer's bias?

I've many times had that "this is junk" feeling when staring at a big pile of foreign code that I wanted to make do something new, but more often than not, as I learned how it actually worked, I realized it wasn't junk at all. Modifying and refactoring old known-working code never sounds as much fun as writing something new "from scratch", but it's usually the more effective approach. (You're unlikely to really understand the problem until you've worked with the old code.) This is only more true when the existing code is both battle tested and friendly to modification, like OpenACS.

Taking a rather large toolkit like OpenACS, and then deciding to write your own users table from scratch, is, as anything other than an academic or tutorial exercise, a pretty strange approach. OpenACS's single biggest strength is arguably its well thought-out data model, so totally ignoring a core part of it like the users table makes no sense.

You'd probably have been better off explaining what custom behavior you want your site's "login and registration system" to have, and how you're having trouble using OpenACS to do it. Since you didn't tell anyone what your actual goal is, you're a lot less likely to get the advice that would be most effective in solving your problem.