2010-09-13 17 views
0

J'ai un contrôle utilisateur qui est chargé de présenter la création et le changement d'utilisateurs. Le usercontrol est lié à une entité délivrée par un service RIA:Meilleure approche: Définir/modifier le dialogue de mot de passe

[MetadataType(typeof(User.UserMetadata))] 
public partial class User 
{ 
    internal class UserMetadata 
    { 
     protected UserMetadata() {} 

     [Required] 
     public string Name { get; set; } 

     [Exclude] 
     public string PasswordHash { get; set; } 

     [Exclude] 
     public int PasswordSalt { get; set; } 

     [Required] 
     public string ShortName { get; set; } 

     [Include] 
     public IEnumerable<UserRole> UserRoles { get; set; } 
    } 

    [DataMember] 
    [RegularExpression("^.*[^a-zA-Z0-9].*$", ErrorMessageResourceName = "BadPasswordStrength", ErrorMessageResourceType = typeof(ErrorResources))] 
    [StringLength(25, MinimumLength = 6)] 
    public string NewPassword { get; set; } 
} 

Lorsque vous créez un nouvel utilisateur, le champ « NewPassword » est nécessaire - mais lorsque la modification des propriétés d'un utilisateur existant, il n'est pas (il est utilisé pour les changements de mot de passe).

Quelle est la meilleure approche pour résoudre ce problème? J'ai plusieurs idées, mais ils ont tous se sent un peu merdique :-)

Merci

Répondre

1

Il semble que vous passez vos mots de passe en cours de retour à l'interface graphique. Il n'y a pas besoin de faire ça. Cela créerait un trou de sécurité potentiel

Suggère que vous traitiez le changement de mot de passe comme un appel de service distinct, et pas seulement comme un simple exercice d'édition d'enregistrement. Les services RIA prennent en charge Invoke Operations qui sont des appels directs essentiellement arbitraires à votre service RIA. La seule restriction sur les opérations Invoke est qu'elles ne peuvent pas renvoyer des types complexes (pas un problème pour cet exemple).

passer votre identifiant d'utilisateur connecté actuel , le mot de passe actuel (codé) et le nouveau mot de passe (codé) et faire tout le côté serveur de travail. Renvoie une valeur booléenne de succès simple.

Juste quelques suggestions, je suis heureux de voir les idées des autres sur celui-ci :)

+1

Je vais second ceci. Vous ne devez jamais inclure de mots de passe dans vos entités. Au lieu de cela, faites-les paramètres de la méthode et assurez-vous qu'ils ne sont pas inclus dans l'uri (utilisez POST). En outre, passez à l'utilisation de https sur deplyment. J'ai posté quelques conseils sur la façon de le faire avec l'adhésion ASP.NET et comment utiliser https sur mon blog. http://blogs.msdn.com/b/kylemc/archive/2010/05/10/using-asp-net-membership-in-silverlight.aspx http://blogs.msdn.com/b /kylemc/archive/2010/05/26/ria-services-using-https.aspx –

+0

Non, je ne pousse jamais le mot de passe à l'interface graphique, la propriété NewPassword est "calculée" et ne correspond pas à un attribut de table. C'est juste là, pour prendre les changements de mot de passe et les mots de passe initiaux de l'utilisateur. Juste pour être sûr. Votre proposition est de supprimer cette propriété et d'introduire un service qui est seul responsable de définir/réinitialiser le mot de passe? Ça a l'air ok - même si je ne comprends pas vraiment la différence. – Daniel

+0

@Daniel: Si vous envoyez seulement le mot de passe déjà crypté, votre idée fonctionne également. Êtes-vous réellement crypter votre mot de passe sur le client? C'était ma principale préoccupation. –