website

wanted to add blogs to the /project/project-name pages so that they would be listed also, since these are likely (hopefully) to be a good source of daily project progress.

the fix turned out to be easier when the problem was recognized. the project page script already gets all the nodes for a named project, it then sorts them by type. for user-defined types we need to trim down the node list to only those tagged with the specific user defined type. for a core type, like blog, we don't need the extra queries since the type is embedded right in the node table. we can go right to selecting the "blog" subset of project nodes.

i've researched the mailing list issue a little.

the [listhandler module doesn't work in drupal 4.3|http://drupal.org/node/view/4985](scroll down to "listhandler does currently no"), so i'd have to upgrade to 4.4. and that link direction reveals a problem. the replies to a node aren't individually referenceable. this might be resolved with a theme, but it's not a feature out of the box.

looking around drupal.org some more brings me to [another discussion|http://drupal.org/node/view/6621] mentioning a [mail2forum|http://m2f.sf.net] project which does nice (complete?) integration of lists with phpbb fora. this brings up another issue: using best-of-breed apps. [from the looks of it|http://www.phpbb.com/styles/forum/viewtopic.php?t=192127&style=68], phpbb is a much better forum engine than the one in drupal.

drupal 4.4.0 has been released. reviewed the module list. looks like they've updated all modules for 4.4. this includes the listhandler, which is what i'm interested in. there are a number of other interesting modules including an update to the wiki module, a groups module, and others i've reviewed.

would probably be good to keep this testing on a separate site. will ultimately require importing to cvs and migration of main site

I've updated our taxonomy for the site a little. This primarily affects the order of the taggable items you see when submitting content.

*The "section" vocabulary is now listed first (this reflects it's importance in tagging content). For example, this is a "news" item.
*The "project" vocabulary is second because most of the time you should be working on something related to a project. Please classify your entries. (If you think a project is missing, let me know)
*Finally, our old "nmi" section has been renamed to "tools" to better reflect its function. These terms will reflect what tools relate to the item being posted.

It should be possible to write a kde service that listens for bookmark updates and automatically adds them to drupal, preferably via an xmlrpc call.

It would also be necessary to add a "Add Bookmark with Comment" and/or "Add Edited Bookmark" option in the bookmark save dropdown. This would bring up a more complete ui to enable adding a description and (better) topic affiliation. The affiliation should be context from the bookmark folder though.

the switch identity option really needs to replace the logout option (or maybe be in addition to it). this has an impact on the scope of the session.

it's a good question to think on who we are accross all these applications. our login identity really needs to span all the applications that we will integrate. so there needs to be a single def of our role or logged in id.

so if we switch to an annoymous user we are really logging out not only of the local app but of the site webiso session as well (and all other site applications). this is somewhat complicated since is means destroying the pubcookie sess cookie for all apps in our domain and then ensure that each per-app session is aware of the identity change. the question also arrises what this all means in a shib context or if I switch from one "global" user identity to another.

I was poking around the drupal site and saw this article:

http://drupal.org/node/view/5477

It's a nice review by someone who's new to drupal but not new to
computers. It's also interesting to see that it's from a guy at SSC and
that they are using it for a couple of their sites. There's some good
guidance on how to use a CMS, plus a link to SSC's CMS review blog:

http://www.linuxgazette.com/node/view/220

While it doesn't have much of a comparison except to PHPNuke, it's nice to
see that they picked it for similar reasons we did.

Finally, theres an interesting thread at this other drupal site that

I'm to the point where the role change concept should definitly replace the login concept. You are "logged in" when your session starts, not when the login button is pressed.

The first time you come to the site, the only thing that will happen is that you will be identified as an anonymous user. You'll have the option of changing your role. The user block will be changed to a role selection tool and it will reflect your current role, a summary of permissions with that role, and give you the option of changing your role.

Pressing the change role botton/link will take you to an ssl protected page. This is to enable the reading of any existing secure cookies for the domain, eg. webiso cookies. The page will have options similar to the following with radio button selection capability

When I go to the pubcookie protected resource page both the presession and the checksum cookie are marked "secure" by the mod_pubcookie, so they won't be sent accross insecure channels (non ssl) . This is important from our perspecitive because if the user comes in via http (no ssl) then we wont' see the pubcookie cookies. So, by default a user will be forced into an annoymous state when they visit the site via http.

If they press the login button we could receive the cookies then. We could have the option of dropping to non ssl then if the php session allows it (assume it does).

It might be desireable to replace the login block with just a login link that could then give the person a few options about becoming logged in. The user block could say who you are logged in as, similar to what it shows when logged in. So when you are annonymous it shows you as anon and your permissions. You then have the option to become non-anon, ie, change your privilage level. The page could tell the user that they currently have a recogonized login session and can change to that identity.

An issue to deal with in the sso environment is whether to protect the entire session with ssl or just the login.

This is really a problem for any session-based interaction.

The question is, do you need to protect against the hijacking of sessions? And for websso, do you need to protect against the hijacking of a session that could potentially span many applications.

It's also important to remember that all ssl will do is protect these nuggets (session cookies) while they are in transit. They won't protect them once stored in the client browser. This may be where the bigger security issue comes into play.