Asfand Yar Qazi said the following on 11/22/2009 10:10 AM:
> 2009/11/21 Anton Aylward <>:

> I'm not going to skimp on forum features just because it has to be in
> Ruby on Rails - phpBB it is, because the rich feature set is worth it
> (and it's free compared to vBulletin).  The main page has to have
> snippets of the latest blog entries, the latest forum posts, and a
> single username/password must be able to access all of these.  Using
> separate apps makes this more difficult, but not impossible - I just
> have to delve into the database of each one and extract the text
> myself.

It doesn't have to be like that!

>> SSO is a very fuzzy concept.  ...
> That's why I want to use a single engine for everything - RBAC becomes
> easier.  If I have to use other software, I'll basically be creating
> accounts and logging people into them on the other software when they
> log onto my app.  But phpBB, for example, has its own RBAC scheme, so
> that's ok.  It means doubling work of administrators when assigning
> roles (first on the app, then on the forum software), but from the
> visitor's point of view, it seems consistent, because they only have
> to create an account once.

I think you're labouring under a misapprehension.

Certainly if you use a PHP engine for the forum and Radiant Engine for
the other stuff you'll have this matter of hand copying.  But there are
simpler ways to do this.

I once did up an application with a simple portal page and simple and
SEPARATE account manager application/database.  The account manager did
more that 'just' access control, it also determined which of a number of
databases the user could connect to.[1]

Think about that for a moment.  Its neither a new nor revolutionary concept.

Single sign On in a large windows environment is done with something
like an LDAP database.  I don't particularly like LDAP, but its there
and there's a lot of it.  A plugin that overrides Radiant's existing
authentication isn't going to be difficult.  Does one already exist?

Once a user has been authenticated to the domain a cookie can contain
(signed and encrypted so it can't be hacked!) all the information that
"does" the SSO.

How do you think SSO in web based applications work anyway?  The HTTP
protocol is connectionless, so ANY login system has to use cookies to
simulate a connection.

I'm sure if I looked I could find a few media companies - ZDNet
perhaps?? - that simulate SSO across multiple engines and subdomains
using domain-level cookies.    I know for sure my Amazon Affiliate login
 also authenticates me to the store.

I'm a strong believer in simplification, and one of the axioms is "Each
Thing Does One Thing and Only One Thing".  Overloading a single engine
to do all you want sounds like a recipe for disaster.

[1] See Rick Smiths' book "Authentication"
    P122: "Indirect Authentication dresses the scalability problem
    posed by sites with a single user population but multiple points of
    service. Even a site with just two servers will want to avoid the
    headache of maintaining consistency between two separate
    authentication databases."

A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders, give
orders, cooperate, act alone, solve equations, analyze a new problem,
pitch manure, program a computer, cook a tasty meal, fight efficiently,
die gallantly. Specialization is for insects.
        -- Robert A. Heinlein, "Time Enough for Love"
Radiant mailing list

Reply via email to