|
No you have the IdentityDbContext in in your MVC application and in the DataAccess layer your regular DbContext.
|
|
|
|
|
Hmm how will the IdentityDbContext know about my ApplicationUser in my data (EF Models) solution? Hmmm may give it a rest for tonight mind is not working correctly
Simon Lee Shugar (Software Developer)
www.simonshugar.co.uk
"If something goes by a false name, would it mean that thing is fake? False by nature?" By Gilbert Durandil
|
|
|
|
|
The IdentityDbContext has already all Identity related models defined. If you like to customize it, do it like I described it previously:
Create a layer that is derived from UserStore<identityuser>, override all methods and fill them with you custom logic, and map the identity models to your custom models. AND VERY IMPORTANT: If you don´t want that the UserStore uses a default DbContext you have to define an invalid connection string in the constructor of the UserStore!
greetings
|
|
|
|
|
Hello folks,
I want to store login credentials for a SMTP server which should be stored encrypted.
In your opinion:
Where should I store the credentials?
How they should be secured?
Why do you think should I use your suggestion?
greetings
Nico
|
|
|
|
|
Hi Nico,
You can store the credentials in SQL Database.
They can be secured by using Hash encryption (one way encryption).
|
|
|
|
|
That won't work. See Bernard's message below for why it won't.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
|
I guess it is your application which tries to communicate with the SMTP server.
Hence the application must be able to retireve the clear text password when connecting to the server. Consequently, you cannot hash the password, but you must encrypt it. This also adds the question of how to store the key and the salt value.
Next question is: who configures your application? Is it the "user" who enters his personal SMTP credentials or is it an administrator of the user's company who does so (and applies the same configuration to all installations of the application in the company)? Depending on the answer, you may use a user-specific settings file, a program specific settings file, the *.exe.config file, store data in a database, etc...
Also note that the .exe.config file contains a connectionStrings section, which can be "automatically" encrypted and also used for this purpose.
|
|
|
|
|
Hello Bernhard,
thank you for your reply!
The SMTP credentials are configured by an Administrator and not by the end user, so the SMTP is a global SMTP.
Ok, and in case of an ASP.NET application, this would be the web.config, wouldn´t it be?
To secure the configuration section would this be the appropriate way?
greetings
Nico
|
|
|
|
|
You identified the right section for web.config. I'd suggest to enter the credentials and do the protection during the deployment of the application.
|
|
|
|
|
Use the System.Security.Cryptography.ProtectedData class. It's designed for exactly this task.
|
|
|
|
|
Thank you for your reply, but isn´t this class´ purpose only for encrypting and decrypting data with the dapi mechanism?
|
|
|
|
|
It is. You need to decide yourself, where to store encrypted data - config, settings file, etc.
|
|
|
|
|
Yeah DataProtection api is the way to go
|
|
|
|
|
I'm using Visual Studio 2010.
When I was compiling the execuables that contains 19 different dlls. Each dlls have dependency on other dlls. I just got bumped into a couple of incorrect dlls' date of creation.
For example, one dll 'error.dll' is being depended by half of the dlls which consists of error codes and its translations. some of the dlls has error.dll referenced being pointed to the error/bin/debug and others was pointed to error/bin/release.
When compiling overall solutions, the exe ended up having the wrong version of error.dll. Is there a better way to control the location of reference files... I mean a way to test or ensure that these references are pointed in their right places to ensure that these dlls are pulled correctly?
Thanks... respond back if you have any questions or answers.
~ Ron Boucher
|
|
|
|
|
There are two potential solutions that I normally use.
If you have the DLL that you are depending on in your solution, use a solution reference to refer to it - right click, Add Reference > Solution.
If the reference is to an external DLL, I copy that DLL into a common location (e.g. lib) that exists in the relative path to the solution and all projects use the DLL from that location. The advantage of this is that you can store this in source control, and you can easily sort out versioning issues.
|
|
|
|
|
Hmm I like the 2nd suggestion (external dll). That would sure help out!
|
|
|
|
|
If you have the source for the dll(s) then the Project reference is a much better solution!
|
|
|
|
|
Can you explain why?
Is this the step that you're referring to:
1) right click on "Reference" node
2) Add Reference
3) Click on "Projects" tab
4) Select the dlls to reference
|
|
|
|
|
If the code is a logical part of your solution then having a solution reference means that a full build should never be out of step.
|
|
|
|
|
Yes, first you add the Project for the dll Assemblies to the Solution and then you do the Project reference(s).
The reason I said it is better is that:
VS will keep track of whether you're building Debug or Release and make sure the dll is consistent with the rest of the Solution.
The correct dll will (can) be automatically copied to the same folder as the rest of the Solution so everything is consistent.
The version of the dll Assembly will be consistent in the Solution. Especially useful for keeping track of things in Source Control.
(If you modify the dll, then you can be sure the rest of the solution is referencing the one you intend.)
|
|
|
|
|
Thanks! I'll get that fixed right away.
|
|
|
|
|
That's excellent! We've been having these problems (referencing wrong dll) for a while now! This will solve that!
|
|
|
|
|
Hello, I am using word automation in c#, no problem with merge fields but I need to do another action: I need to add to my Document a Header and a Footer from another document. Can you help me? Tanks a lot!
|
|
|
|
|
What have you tried?
Where are you stuck?
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
