![]() | |
![]() |
| | Thread Tools | Search this Thread | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
I'm building an n-tier application with data access, application and UI The application will eventually be publicly available for download and installed on end-users machines. How can I protect my middle tier and DAL assemblies from unauthorised access so that a 'clever' user cannot add a reference to one of my separate assemblies and start calling it's public members. Marking members as Internal only works for classes that are 'inside' the same assembly. |
#3
| |||
| |||
|
|
I'm building an n-tier application with data access, application and UI layers in separate projects and hence separate assemblies. MyProjectUI.dll MyProjectApp.dll MyProjectDataAccess.dll etc... The application will eventually be publicly available for download and installed on end-users machines. How can I protect my middle tier and DAL assemblies from unauthorised access so that a 'clever' user cannot add a reference to one of my separate assemblies and start calling it's public members. Marking members as Internal only works for classes that are 'inside' the same assembly. Any tips or suggestions would be greatly appreciated. |
#4
| |||
| |||
|
|
You may add the constraints on the calling assembly. Assembly.GetCallingAssembly() And then verify the assembly. Verify against all the parameters - name, version, culture and public key token. Although you cannot trust the other party, but definitely you can verify the other party. You may also want to do some tricks: In the calling assembly, put some embeeded resources, say public key or a bitmap or a secret-key (though nothing is secret because of decompilers). From the DAL assembly, verify that the resources exist untampered. If you are using .Net 2.0, checkout the topic of "Friend Assemblies". -- Happy Hacking, Gaurav Vaish http://www.mastergaurav.org http://www.edujini.in ------------------- "Anthony Bouch" <ab (AT) nospamever (DOT) com> wrote in message news:uAA03qSeGHA.2076 (AT) TK2MSFTNGP04 (DOT) phx.gbl... I'm building an n-tier application with data access, application and UI layers in separate projects and hence separate assemblies. MyProjectUI.dll MyProjectApp.dll MyProjectDataAccess.dll etc... The application will eventually be publicly available for download and installed on end-users machines. How can I protect my middle tier and DAL assemblies from unauthorised access so that a 'clever' user cannot add a reference to one of my separate assemblies and start calling it's public members. Marking members as Internal only works for classes that are 'inside' the same assembly. Any tips or suggestions would be greatly appreciated. |
#5
| |||
| |||
|
|
Thanks Gaurav. Interesting and helpful. |

![]() |
| Thread Tools | Search this Thread |
| Display Modes | |
| |