Development

#2158 ([PATCH] Custom error when account is disabled)

You must first sign up to be able to contribute.

Ticket #2158 (new enhancement)

Opened 1 year ago

Last modified 3 months ago

[PATCH] Custom error when account is disabled

Reported by: ericbartels Assigned to: fabien
Priority: minor Milestone: plugins
Component: sfGuardPlugin Version: 1.0.0
Keywords: IsActive, Custom, Error Cc:
Qualification: Design decision

Description

I had the requirement of knowing if the users account is disabled after he successfully authenticated himself.

If I get a custom error indicating that the account is disabled I can use a custom error message. This is much more flexible.

Attachments

sfGuardUserPeer.php.patch (0.5 kB) - added by ericbartels on 08/31/07 20:41:38.
sfGuardUserValidator.class.php.patch (1.4 kB) - added by ericbartels on 08/31/07 20:41:50.

Change History

08/31/07 20:41:38 changed by ericbartels

  • attachment sfGuardUserPeer.php.patch added.

08/31/07 20:41:50 changed by ericbartels

  • attachment sfGuardUserValidator.class.php.patch added.

10/01/07 07:48:29 changed by dwhittle

  • qualification set to Design decision.

12/24/07 10:47:40 changed by Pascal.Borreli

the patch doesn't respect code standards.

it's based on old version of sfGuardPlugin model structure

i don't think it's a good idea to customize error messages on a login system. If the admin put a user inactive, it's for a specific reason that the user maybe doesn't have to know : user deleted, inactive, banned, expired, bad password, ldap disconnected ...

let's see what other ppl think :)

(follow-up: ↓ 4 ) 12/24/07 12:00:16 changed by ericbartels

I will update the patch later on :)

I think there should be away that the "login process" can give you a feedback of what was wrong (expired, banned, ...). In certain situations (like mine) its a must to get this feedback and let the user know whats wrong.

(in reply to: ↑ 3 ) 07/16/08 16:28:01 changed by Philippe Gamache

I do agree that sometime, you need it, but usually (for security reason and to be more polite) you don't do that kind of behavior.

So correct your patch, and maybe add a configuration option, to make it available or not.

Because it's not there now, it should be disable by default.

Maybe only adding it to the symfony 1.1 version of the plugin.