Y a-t-il un risque que l'objet SqlConnection soit une propriété pour un seul exécutable?

Question

J'ai l'habitude de concevoir qu'un objet SqlConnection soit rempli par un formulaire enfant, affichant le formulaire enfant, établissant l'objet SqlConnection et renvoyant l'objet renseigné au formulaire parent où l'exécution se poursuit. .NET 2.0 ou plus récente 0 comme suit:

formulaire parent:

public SqlConnection sqlcon; //should be property but made it public for this example 
public MainForm_Load(object sender, EventArgs e) 
{ 
    Login frm = new Login(this); 
    frm.ShowDialog(); 
    if (this.sqlcon == null) 
    { //no login 
     this.Close(); 
    } 
    //else, continue execution 

} 

Login Form:

Mainform parent; 
public Login(RandomParade frm) 
{ 
    InitializeComponent(); 
    parent = frm; 
} 

private void btnOK_Click(object sender, EventArgs e) 
{ 
    //code to capture login details from textboxes 
    //test connection  
    parent.sqlcon = new SqlConnection("connection string with login details here"); 
    this.Close(); 

} 

Comme il est compilé en un seul exécutable (modificateurs d'accès dll traités séparer etc ...), est-ce que l'objet sqlConnection public présente un risque de sécurité? Quelqu'un pourrait-il prendre l'information à l'exécution? Quelle serait une meilleure implémentation de la transmission des informations de connexion à un formulaire "principal"?

Answer 1

Comme .NET maintient un connection pool en interne (sauf s'il est éteint), vous devriez passer un connection string à la place, et l'utiliser lors de la création de nouvelles connexions.
Cela vous permet de conserver les informations de connexion "thread-safe" en créant une nouvelle connexion pour tout ce que vous devez faire (par rapport à un lot, par exemple).

Il n'y a aucun risque que la connexion soit piratée au moment de l'exécution, car celle-ci devrait être regroupée dans un domaine d'application. (Il y a des moyens, mais c'est une autre discussion).

Cela peut sembler très inefficace, mais en raison de la mise en pool d'arrière-plan, le passage d'une chaîne de connexion fonctionne parfaitement. Donc, pour répondre à votre question: il n'y a pas vraiment de risque de sécurité, mais il y a un risque pour la sécurité des threads, alors passez une chaîne de connexion au lieu d'une connexion. Cela fonctionnera plus facilement pour vous.
Aussi, rappelez-vous de disposer de vos SqlConnection s et SqlCommand s lorsque vous avez terminé avec eux;)