Prev: Open an external file from a formular
Next: Create Desktop Shortcuts
From: Bob Alston on 31 Dec 2009 16:21
Perhaps I was not clear enough for someone to respond to my earlier
posts. Let me rephrase.

I am trying to figure out the practical access privileges/security
settings for using Sharepoint 2010 to host an Access 2010 app that users
would download from Sharepoint2010 and run on their own PC using Access
2010. The data would be stored in sharepoint 2010 tables.

So far I have been able to publish the data from an Access 2010 app to
sharepoint and publish the app itself to sharepoint. If I go to the
sharepoint site I published to, and select options, I can download the
app. From there I can run on a local PC with the data still ultimately
stired in Sharepoint 2010.

1) Tracitionally, when i develop Access apps for others, I often
restrict their access to running the app through the menus and forma I
provide. How can I restrict users who download the app from Sharepoint
to not be able to update the access app - locally on their PC and on the
Sharepoint master copy?

2) What should the security settings for a user who can update/change
the access app?

3) Is there a way to make the downloaded app behave like an access MDE?

4) When I go to the sharepoint site, I can see options allowing me to
export any table to excel. What if I do not want to allow my users to
access data in raw form and do not want them to be able to export data
to Excel?

5) Is there any easier way to allow users to download the access app
other than by knowing to click on OPTIONS and then SAVE? Perhaps
something better named?

Thanks to anyone who can provide answers.

Bob Alston
From: Banana on 21 Jan 2010 00:54
Bob Alston wrote:
> Perhaps I was not clear enough for someone to respond to my earlier
> posts. Let me rephrase.

No you were quite clear. The trouble is that I think not many testers
has had chance to broach this subject. I can only tell you that it took
me a while to wrap my brain around Sharepoint's security model before I
could give any meaningful answer.

> 1) Tracitionally, when i develop Access apps for others, I often
> restrict their access to running the app through the menus and forma I
> provide. How can I restrict users who download the app from Sharepoint
> to not be able to update the access app - locally on their PC and on the
> Sharepoint master copy?

There is a way to modify the what I think is called "Title Bar" but I've
yet to find a means to doing this. However, I did briefly saw someone
else's demo on AccessHosting.com and noted they did away with the
default title bar so this is an nonissue.

I was able to suppress the "Actions" button by modifying a XML file. But
frankly that was quite hackish, and I'm still studying the Sharepoint
how to manipulate those. It's complicated by the fact that sites created
by Access Services isn't available in Sharepoint Designer (they probably
have a good reason- editing in Access then editing in Designer is a sure
recipe for disaster)

But the answer would lie in modifying the existing XML files so the
title bar either do not display the buttons or suppress it entirely.

> 2) What should the security settings for a user who can update/change
> the access app?

This is completely managed by Sharepoint, not Access. None of what we
would do to set up security in Access to date would apply to web
database, though keep in mind it is possible to have a hybrid database
mixing web objects with client objects. If one want to allow downloading
the file to use the full functionality, you still may want to use
traditional approach for securing those, but in context of web browsers,
it's Sharepoint security that matters. You would manage this via
Permissions page on the published site.

> 3) Is there a way to make the downloaded app behave like an access MDE?

You certainly can publish an ACCDE, but it must be realized that ACCDE
is of less value due to the fact that web databsse can only use macros
and macros are editable in ACCDE. One possible precaution is to not use
standalone macros but rather embed macros inside the forms/reports.

> 4) When I go to the sharepoint site, I can see options allowing me to
> export any table to excel. What if I do not want to allow my users to
> access data in raw form and do not want them to be able to export data
> to Excel?

You can either as mentioned earlier, suppress the button leading to the
Modify Application button or deny the users the permissions to "View
Application Views" via Sharepoint Permission page.

> 5) Is there any easier way to allow users to download the access app
> other than by knowing to click on OPTIONS and then SAVE? Perhaps
> something better named?

I would think you may want to provide this via a form within the web
database- set up a little repository on Sharepoint, upload a copy there,
then sync the database.

> Thanks to anyone who can provide answers.

Note this is just after my first successful attempt at setting up the
permissions and locking the non-administrator user out from the Modify
Application pages (as well other Sharepoint pages) while still having
the permissions to interact with the web database inside a web browser
(edit, add, delete) and no ability to download the file via Actions
button. As noted earlier, I am not all sure that what I've done could be
the best thing to do but hopefully that's start toward understanding how
things work.
From: David W. Fenton on 21 Jan 2010 13:51
Banana <Banana(a)Republic.com> wrote in
news:4B57EC08.2050909(a)Republic.com:

> None of what we
> would do to set up security in Access to date would apply to web
> database, though keep in mind it is possible to have a hybrid
> database mixing web objects with client objects. If one want to
> allow downloading the file to use the full functionality, you
> still may want to use traditional approach for securing those

I'm confused.

For plain old SharePoint distribution of your front end (like any
other file, i.e., not involving Access services at all), sure, you
can upload a secured MDB and the supporting workgroup file and still
use Jet ULS.

But it's only ACCDB that is compatible with Access services, so
there is no security available at all (database passwords are not
security).

So, I'm having trouble parsing the quote portion of your paragraph
above.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 21 Jan 2010 13:53
Banana <Banana(a)Republic.com> wrote in
news:4B57EC08.2050909(a)Republic.com:

> Note this is just after my first successful attempt at setting up
> the permissions and locking the non-administrator user out from
> the Modify Application pages (as well other Sharepoint pages)
> while still having the permissions to interact with the web
> database inside a web browser (edit, add, delete) and no ability
> to download the file via Actions button. As noted earlier, I am
> not all sure that what I've done could be the best thing to do but
> hopefully that's start toward understanding how things work.

I don't understand why Bob's question is not getting an answer from
somwhere. Surely somebody among the MVPs somewhere or someone at MS
knows the answers to his questions, but I'm not seeing anything (and
he's asked in the Technet 2010 beta newsgroups, too).

Bob is asking about a garden-variety distribution scenario, and it
seems nobody has given any thought to what to me seems a very
obvious use case that should already be completely worked out.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on 21 Jan 2010 14:12
David W. Fenton wrote:
> I'm confused.
>
> For plain old SharePoint distribution of your front end (like any
> other file, i.e., not involving Access services at all), sure, you
> can upload a secured MDB and the supporting workgroup file and still
> use Jet ULS.
>
> But it's only ACCDB that is compatible with Access services, so
> there is no security available at all (database passwords are not
> security).
>
> So, I'm having trouble parsing the quote portion of your paragraph
> above.

Well, I don't consider database passwords to be a real security but it
doesn't change the fact that some people out there do want to secure the
file in some way, be it using AD queries to check the user's permissions
before allowing them to go to a certain form, using ACCDE to prevent
unauthorized editing, rolling out a DIY security (which I personally
think is waste of time and fairly risky proposition but again, I'm only
describing what is being done by others). Anyway, this is what I was
referring to as 'traditional approaches', which certainly couldn't
include ULS as you noted- not available in ACCDB/ACCDE files.

One more traditional approach was also to make use of Windows Filesystem
permissions to keep out the non-users- this wouldn't certainly apply in
context of Sharepoint distributing the file, however, I'm fairly sure
Sharepoint can be configured to behave in similar manner, not allowing
nonusers to download the file at all.

The point being made is that if you still want to secure the hybrid
database that is distributed via Sharepoint, the traditional approaches
still applies for the client objects because the Sharepoint security
model will only deal with Sharepoint objects and client objects aren't
subject to Sharepoint's security (albeit in an indirect fashion should
the objects reference Sharepoint objects).

I've yet to find out whether it is possible to tune the Sharepoint
security to act effectively as RWOP or RunAs so that only the
application itself has the permissions to update the lists and denying
the same thing to the users, and that is what I hope to find out
eventually. As I said, this is only my first attempt at understanding
the security model and at least it can be nominally secured as described
in my prior post.

I hope this help clarifies things...
 |  Next  |  Last
Pages: 1 2 3
Prev: Open an external file from a formular
Next: Create Desktop Shortcuts