"MGFoster" <me@privacy.com> wrote in message
news:g5jhc.2768$eZ5.2688@newsread1.news.pas.earthl ink.net...[color=blue]
> Freeserve wrote:
>[color=green]
> > Not sure whether this is the right group, but I can't find anything in[/color][/color]
the[color=blue][color=green]
> > .NET groups and my apologies if this has already been covered or is
> > considered "off subject".
> >
> > I am looking at using an Access database to hold data which will be[/color][/color]
handled[color=blue][color=green]
> > via VB.NET and I am not sure about some of the security aspects. I am[/color][/color]
going[color=blue][color=green]
> > the .NET route as part of the application involves using a Pocket PC and[/color][/color]
I[color=blue][color=green]
> > don't want part to involve deploying msaccess.exe and so on as well as[/color][/color]
the[color=blue][color=green]
> > .NET stuff. Including a .mdb file in with the .NET stuff is OK.
> >
> > With an Access front end it is possible to stop users from running RWOP
> > queries except when called from an Access form by putting a function in[/color][/color]
the[color=blue][color=green]
> > query which checks where it is being called from by using[/color][/color]
CurrentObjectType.[color=blue][color=green]
> > I am looking for something similar to use with VB.NET. However, as far[/color][/color]
as I[color=blue][color=green]
> > can see, if the VB.NET app calls the RWOP query in the Access database,
> > there is not much you can do to stop them calling the RWOP query[/color][/color]
themselves,[color=blue][color=green]
> > e.g. from their own Access database. My question is: How to I stop users
> > from running queries or accessing tables in the Access back end while[/color][/color]
still[color=blue][color=green]
> > giving my VB.NET "front end" sufficient access, please?
> >
> > When I've done Access apps that require reasonable security I've done[/color][/color]
things[color=blue][color=green]
> > like:
> >
> > 1) Use user-level security.
> > 2) Develop using one MDW file, but not allow users to use this. Instead[/color][/color]
they[color=blue][color=green]
> > use the default system.mdw. Users, therefore, enter the app as the Admin
> > user from system.mdw and the app then checks their Windows ID to specify
> > which parts of the app they can access.
> > 3) Do a proper removal of the Shift bypass stuff so they are forced into
> > running code that picks up their Windows ID. Either that or ID's are[/color][/color]
held in[color=blue][color=green]
> > tables and used from there, with the users having to enter an ID and
> > password to authenticate themselves.
> >
> > The problem seems to be that if I am using user-level security for the
> > Access database, VB.NET requires a user ID and password for this that[/color][/color]
also[color=blue][color=green]
> > requires the existence of - and physical access to - an MDW file with[/color][/color]
those[color=blue][color=green]
> > details in. This is where the security hole appears to be. As many[/color][/color]
people[color=blue][color=green]
> > know, if a user has physical access to a .mdw file, there are tools[/color][/color]
around[color=blue][color=green]
> > that will let them see all groups, ID's and passwords in that .mdw file.[/color][/color]
I[color=blue][color=green]
> > also know that it is possible for some people to break into a .mdb file[/color][/color]
even[color=blue][color=green]
> > without the developer's .mdw file, but if people are that desperate to[/color][/color]
get[color=blue][color=green]
> > into my app, well, they need to get a life. The level of sensitivity of[/color][/color]
the[color=blue][color=green]
> > data is such that I need "only" to stop people running RWOP queries that
> > they shouldn't be running.
> >
> > The best I can think of is to give the .mdw file a non-standard name,[/color][/color]
e.g.[color=blue][color=green]
> > MyPretendName.dll, and try and hide it somewhere on the user's PC other[/color][/color]
than[color=blue][color=green]
> > in the application's own folder, in which case I then need to find a way[/color][/color]
of[color=blue][color=green]
> > deploying it there and I haven't got that far in my understanding of[/color][/color]
..NET[color=blue][color=green]
> > application deployment to be able to do that. It doesn't appear a very
> > robust way to do it either.[/color]
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Why not use SQL Server CE ("the compact database"). See this URL:
>
>
http://www.microsoft.com/sql/CE/default.asp
>
> The .NET newsgroups are on Microsoft news servers:
>
> microsoft.public.dotnet.languages.csharp
> microsoft.public.dotnet.languages.vb (not sure)
>
> --
> MGFoster:::mgf00 <at> earthlink <decimal-point> net
> Oakland, CA (USA)
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP for Personal Privacy 5.0
> Charset: noconv
>
> iQA/AwUBQIW90YechKqOuFEgEQLbWgCg9T1HUPU1yQPHAUn1qPaE6I 1CNAMAn1MW
> oZRu2yzCTMazXFPUEQU4TXLn
> =WDbC
> -----END PGP SIGNATURE-----
>[/color]
Thanks for replying. As far as I am aware SQL Server CE only works on
devices running the .NET Compact Framework and, though my app will include
this and I may well use SQLSCE for that part, I want to use Jet/Access to
store data on the PC for various reasons, rather than use SQL Server / MSDE
2000.
Alan
