integrate aspnet membership objects with EF

sophia · July 17th, 2013, 01:34 PM

Hello all,
I am using EF in my project. I want to integrate aspnet membership tables, SPs, Views with EF.
I am using database first approach. It means I am creating DB first and then drag and drop tables into EF diagram.
1. Please tell me how I can integrate membership objects with EF.
2. After integrating will all methods and properties be available directly as we have in case of separate db or we need to do something else to get access.
3. Will there be any requirement of defining connection string in web.config for membership, profile and role providers.
Please help me.
Thanks

Chikelusmith · July 19th, 2013, 07:52 AM

I guess i have the same query..do help anyone on this thing..

Imar · July 30th, 2013, 02:11 PM

Hi there.

I would recommend against this. The Membership API has its own business rules that you'll bypass when mapping to EF.

Why do you want to do this?

Imar

sophia · August 8th, 2013, 12:15 PM

Hi Imar,

Quote:

Why do you want to do this?

Keeping membership details separately needs connection string in web.config.
Which will expose the DB details to some other development team.

Basically I do not want to expose any DB connection to any one, although web.config will not be accessed to normal users but can be seen by development team over FTP.

So, please tell me is there any way to hide DB connection string from development teams or mapping membership objects to EF, without loosing facilities membership API provides?

Thanks

Imar · August 8th, 2013, 04:19 PM

I don't understand the problem or the description (you need a connection string for EF anyway) but if you have the need, you can encrypt the contents of the web.config file.

Cheers,

Imar

sophia · August 9th, 2013, 02:00 PM

I have checked few articles about encrypting web.config file. But I saw that encrypted file can be decrypted easily with reverse process.

So if development team gets encrypted file then will not they be able to decrypt the file?

August 10th, 2013, 02:11 AM

thanks to both for the support ..

Imar · August 10th, 2013, 08:39 AM

Hi there,

Depending on how they have access to the server: yes.

But I don't see the point of this. What are you trying to protect and why in this way? It looks like you're choosing the wrong tool for the job. Typically, your development connection string should be different from your production environment and then you could / should block developers from accessing the production server.

You could hide the connection string but if they own the code, how hard is it to read it programmatically, or to access the database for whatever activity you're trying to block them from.

Cheers,

Imar

sophia · August 15th, 2013, 01:09 PM

Hi Imar,

That's why I want that if it is possible to integrate membership objects with EF so that it connection string be built with EF and may be put in DLL.

Thanks

Imar · August 15th, 2013, 01:37 PM

Quote:

That's why I want that if it is possible to integrate membership objects with EF so that it connection string be built with EF and may be put in DLL.

But I fail to see what the point is. What do you accomplish with this?

Membership has its own logic in stored procedures and code (for example, parsing a password). For that, you'll need to use the Membership classes which in turn need a connection string. Simply mapping the Membership data model in your own EF model is not enough.

Can you elaborate on *why* you try to do all this? From a security, maintenance, and development point of view, none of this makes a lot of sense to me so far.

Cheers.

Imar