Identity Module Stability

[Travis Bradshaw]

I was wondering how the TG developers (Jeff especially) would consider
the relative stability of the Identity module at this point?

As of right now, I've been writing my applications without regard to
authentication because I'm going to need to write a moderately complex
authentication back end for interfacing with Active Directory/LDAP and
KEYS (some customish authentication framework that's in use here at
Kansas State).

My question is kind of simple: should I start on this portion of the
project? Is the identity framework going to remain stable in (at
least) the medium term such that custom SOProviders and such are going
to keep working? Is the code for Identity at a happy place that heavy
customization makes sense?

Thank you for your time,

Travis Bradshaw
c.travis...@gmail.com

[Michele Cella]

Hi Travis,

this applies to everything and not only identity: no API changes will
happen in the 1.0 branch, only bug fixing.

The trunk is open for 1.1 features, but IIRC 1.1 will not ship before
the end of this summer.

Ciao
Michele

[Jeff Watkins]

I contributed the code to Identity and Visit Tracking. Where it goes from here is entirely up to the TG community.

On 2 May, 2006, at 1:24 pm, Travis Bradshaw wrote:

I was wondering how the TG developers (Jeff especially) would consider

the relative stability of the Identity module at this point?

--

Jeff Watkins

http://newburyportion.com/

Getting an education was a bit like a communicable sexual disease. It made you unsuitable for a lot of jobs and then you had the urge to pass it on. 

-- (Terry Pratchett, Hogfather)

[Andrew Grover]

On 5/2/06, Jeff Watkins <je...@newburyportion.com> wrote:
> I contributed the code to Identity and Visit Tracking. Where it goes from
> here is entirely up to the TG community.

I was considering extending the visit framework to include a "remember
me" feature, as described here:
http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice

How does this sound? Would you agree a visit plugin is the way to go on this?

Thanks -- Andy

[Andrew Grover]

On 5/2/06, Andrew Grover <andy....@gmail.com> wrote:
> I was considering extending the visit framework to include a "remember

> me" feature.

> How does this sound? Would you agree a visit plugin is the way to go on this?

After investigating a little more, it looks like I should just bump
the tg_visit expiry to way in the future, and problem solved with no
further code needed :)

-- Andy

[Jorge Vargas]

actually what you need to do is create a LDAPProvider module, sin ce SO stands for SQLObject, I have been thinking of refactoring that a bit but as Michele says below no api changes so I'm not sure if that will be possible in the near future.

[Jeff Watkins]

A visit represents a contiguous (or as nearly contiguous as we can get with the Web) session of interaction with your Web application. Pushing the expiry out indefinitely defeats this purpose. Other things may tie into the visit key like content popularity and it would be difficult to correlate if the visit lasted forever.

Instead, how about serving an explicit cookie (tg_persistent_user?) that contains a key mapping the visitor to an identity record? You would probably want to put some safeguards in there via signing the cookie, but that's not particularly hard.

On 3 May, 2006, at 12:15 am, Andrew Grover wrote:

After investigating a little more, it looks like I should just bump

the tg_visit expiry to way in the future, and problem solved with no

further code needed :)

--

Jeff Watkins

http://newburyportion.com/

"Not everything that can be counted counts, and not everything that counts can be counted."

-- Albert Einstein

[Travis Bradshaw]

Ah, right. Sorry. I haven't even started researching the problem yet
and botched the naming convention a little.

Generally speaking, it sounds like this is probably stable enough for
me to get started. Thank you for the commentary, everyone.

-- Travis

[Andrew Grover]

On 5/3/06, Jeff Watkins <je...@newburyportion.com> wrote:
> Instead, how about serving an explicit cookie (tg_persistent_user?) that
> contains a key mapping the visitor to an identity record? You would probably
> want to put some safeguards in there via signing the cookie, but that's not
> particularly hard.

Thanks for your guidance, I will pursue that approach.

Regards -- Andy