Hi

I have a project which have classes with properties I want to expose to
certain projects but not to all projects. Or rather it is the underlying
data  which I want to restrict access to.

For example, one solution that I've found was custom properties

Public Property Get MyData(Byval Key as String)
        If Key = "Foobar" then
                MyData = ...
        EndIf
End Property

when the calling program needs to know what is an acceptable key

I'd be grateful of any suggestions as to the best way to achieve this?

Many thanks

Simon

We really need to know more about "who" and "why" you are protecting this
data from. i.e., identify the attacker so as to limit the target.

As an expansion on your example, you might consider providing a required
'constructor' for your initial instance that takes a key. Your code would
then subsequently test to insure both the constructor has been called and
whether or not a particular service can be provided. This would relieve the
client from having to provide a key with every call.

First thought - you probably need two components.

-ralph

I don't know your specific situation, but another method to limit access
is to use interfaces.

A class can support many different interfaces.  Whatever you include in the
interface is exposed to the outside world.  Whatever you don't include
can't be accessed.

For an example, add 3 classes to a new project and paste in the code
below into their respective modules.  You'll see the Admin object has full
access, but the Employee object can only read a couple properties.
Access is controlled by what interface they use.

Your projects can then use whatever interface is appropreate.

HTH
LFS

' Form1 code  ---

Private Sub Form_Load()
Dim EmpAccess As Class2  ' Employee access
Dim AdmAccess As Class3  ' Admin access

  ' Admin has full access
  Set AdmAccess = New Class1
  With AdmAccess
    .Name = "Joe"
    .ID = "B123"
    .Wage = 10.5
  End With

  ' Employee has only read access
  Set EmpAccess = AdmAccess
  With EmpAccess
    Debug.Print .Name
    Debug.Print .ID
  End With

End Sub

' Class3 code  ---  (full access)

Public Name As String
Public ID As String
Public Wage As Currency

' Class2 code  --- (read access)

Public Function Name() As String
'
End Function

Public Function ID() As String
'
End Function

' Class1 code  --- (the data object)

Option Explicit
Implements Class2
Implements Class3

Private mName As String
Private mID As String
Private mWage As Currency

' Class2 code  (employee)
Private Function Class2_ID() As String
  Class2_ID = mID
End Function

Private Function Class2_Name() As String
  Class2_Name = mName
End Function

' Class3 code  (admin)
Private Property Let Class3_ID(ByVal RHS As String)
  mID = RHS
End Property

Private Property Get Class3_ID() As String
  Class3_ID = mID
End Property

Private Property Let Class3_Name(ByVal RHS As String)
  mName = RHS
End Property

Private Property Get Class3_Name() As String
  Class3_Name = mName
End Property

Private Property Get Class3_Wage() As Currency
  Class3_Wage = mWage
End Property

Private Property Let Class3_Wage(ByVal RHS As Currency)
  mWage = RHS
End Property

Thx Ralph

Well I am doing something like that. I have a factory which instantiates
a private class with a public interface. I have another library which
expects an object with this interface and it is there that I want to
ensure that the class implementing the interface is legitimate.

Your suggestion is much better than the idea of CustomProperties

Many thanks

Simon

Larry's suggestion shows the importance of identifying the "attacker". In
his case providing a different Interface could limit access at design-time
but would have no effect if an attacker knew that an alternative interface
existed. Whether or not an object has multiple interfaces is easy to
discover, and any interface can be derived or deduced from any other
interface. Such is the nature of COM.

However, also consider that discovering the "key" may also be easily
discovered by any one that has logical or physical access to a program that
has "exalted privilege". I'm assuming that an attacker would not have such
access, in which case you might consider letting the component/object
determine the key on its own, a la a "licensing scenerio" on a by box or
user account basis.

There is very little a program or component can do to 'secure' itself from
probing. Most security depends on some outside system protection.

Need to know more about the over-all scenario.

-ralph

You've made a good point.  I was thinking perhaps he, or his team were the
developers and users.  Note the OP's first post, whose projects are they?

If they're all in-house, there would be no 'outside' attackers.  Using the
interfaces would be a substitute for (or be an aid to) simple discipline....

As you said, more info is needed to know 'which is best' in his particular
case.

LFS

Sorry I didn't mean to reflect directly on you. Interfaces was the first
thing that popped into my mind as well.

I suspect the OP is attempting to provide a single component that would work
in two environments - a developer that has privileges and developers that
don't. The only practical solution would be to provide a component that
tests for some "licensing" key when instanced.

-ralph

I'm sorry, Ralph/Larry, if I'm not very forthcoming about this but it is
a security scenario and I'm loathed to be too upfront about my specific
situation. I have implemented what is probably a combination of both
your's and Larry's. I fully accept that if it not going to be foolproof.

Basically I am validating web requests prior to giving access to data.
It all happens behind a webservice. However, because the software is
likely to get rolled out to customer sites, my concern was the
admittedly unlikely scenario where some malicious person could, in vb6
parlance, set references to my dlls, instantiate factories/implement
interfaces trying to mimic what a legitimate consumer may do. Could I
architect something to prevent a rogue app from tricking my system into
thinking it was legit consumer. I'm sorry if that's too vague.

I have found both your's and Larry's contributions very enlightening.

Thank you very much again.

The code below gives you the EXE filename that is hosting your DLL. However,
depending on IIS configuration, the EXE name could be IIS process itself or
"dllhost.exe". Also, the user could rename his file to make it match one of
the files that your DLL expect.

Option Explicit

Private Declare Function GetModuleHandle Lib "kernel32" Alias _
    "GetModuleHandleA" (ByVal lpModuleName As String) As Long
Private Declare Function GetModuleFileName Lib "kernel32" Alias _
    "GetModuleFileNameA" (ByVal hModule As Long, ByVal lpFileName _
    As String, ByVal nSize As Long) As Long

Private Sub Form_Load()
    Debug.Print GetEXEFileName()
End Sub

Public Function GetEXEFileName() As String
    Dim hModule As Long
    Dim sEXEFileName As String
    Dim ret As Long

    hModule = GetModuleHandle(vbNullString)
    sEXEFileName = String(2000, 0)
    ret = GetModuleFileName(hModule, sEXEFileName, 2000)
    ' Remove the extra nulls
    GetEXEFileName = Mid(sEXEFileName, 1, InStr(sEXEFileName, Chr(0)) - 1)
End Function

OK.  More food for thought. Thx very much.