[ic] Last Login

[Gert van der Spoel]

> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-
> users-bounces at icdevgroup.org] On Behalf Of Stefan Hornburg (Racke)
> Sent: Thursday, June 04, 2009 1:54 PM
> To: interchange-users at icdevgroup.org
> Subject: [ic] Last Login
> 
> Hello,
> 
> for one of my projects I would like to know the time for the last login
> in
> order to show the user activities which happened since then.
> 
> UserDB can be advised with the "time_field" to store the last login in
> the
> user database.
> 
> My problem is that I don't get a chance to access second last login
> after
> the user is logged in.
> 
> The "postlogin_action" is triggered after the "time_field" column has
> been changed.
> 
> Of course, I could look up the database manually before the user logs
> in, but that isn't the point of the UserDB abstraction.
> 
> Any comments?

1) What about setting a session variable right before the login sub
overwrites the last login time in the database?
(but this is perhaps what you mean with the manual lookup in the database).

index fe7e317..0df24d9 100644
--- a/lib/Vend/UserDB.pm
+++ b/lib/Vend/UserDB.pm
@@ -1546,6 +1546,7 @@ sub login {
                if ($self->{LOCATION}{LAST} ne 'none') {
                        my $now = time();
                        my $login_time;
+                       $Vend::Session->{last_login} = $udb->field(
$self->{USERNAME}, $self->{LOCATION}{LAST} );
                        unless($self->{OPTIONS}{null_time}) {
                                $login_time = $self->{OPTIONS}{iso_time}
                                                ? POSIX::strftime("%Y-%m-%d
%H:%


2) move the change of the time_field until after postlogin_action which
gives you time to get the data before it gets changed.
Unless there are scenarios thinkable that could result in the login sub to
terminate during the postlogin_action execution, resulting in the user being
logged in but the last login time not changed. Then that would not be an
optimal solution.


CU,

Gert