Re: W2k and Front Page Security
From: Roger Abell [MVP] (mvpNOSPAM@asu.edu)
Date: 03/15/03
- Next message: Roger Abell [MVP]: "Re: Password for spcific folder"
- Previous message: Robert Hawkins: "Digital Signature"
- In reply to: Jenny: "W2k and Front Page Security"
- Next in thread: Jenny: "Re: W2k and Front Page Security"
- Reply: Jenny: "Re: W2k and Front Page Security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Roger Abell [MVP]" <mvpNOSPAM@asu.edu> Date: Sat, 15 Mar 2003 08:53:44 -0700
"Jenny" <jklippe@yahoo.com> wrote in message news:012301c2ea72$4434fd90$a501280a@phx.gbl...
> Here we go We now have 16 different web authors for our
> site, each dept maintains their own. I have the site set
> up now using subweb and setting permissions throgh Front
> Page/. We have have contracted out our web redesign to a
> vendor. We have noone here that knows how to code. She
> wants me to use NTFS file permissions instead of subwebs,
> We have sahred drop down menu bar that will need to be
> updated 16 times when changes are made by 16 different
> people. How can I still allow our users to update and
> maintain with Front Page and still have a folder structure
> with NTFS permissions contolling folders.When I set
> permissions and by pass the Font Page control of
> permission I get server error cannot open *file for
> read/write " I have done every fix suggested by microsoft
> for this error and nothing is workin. I need to keep some
> kind of seperate permissions so that others are not
> screwing up anothers pages Please Help
> Thnk you
> .
>
When you start tweaking around at the NTFS level within
FrontPage managed content areas you do really need to
know what you are doing.
>From what little you have said, I assume you had initially
something like
./sitemain
./sitemain/group1
./sitemain/group2
etc
./sitemain/group16
or 17 FP webs nested as shown
and with each having different authors
and now, within
./sitemain
this designer wants for you to have
./sitemain/subinfo
./sitemain/subinfo/group1
etc
./sitemain/subinfo/group16
where these are all part of the one
FP web ./sitemain but have NTFS
to allow authors of groupX subweb
ability to update some info within
./sitemain/subinfo/groupX that the
./sitemain web uses for menu display
in order for the main menu to reflect
changes they have made within their
./sitemain/groupX subweb
Perhaps ./sitemain/subinfo/groupX
actually represents some file within
./sitemain/subinfo/ instead of a
folder, but the idea/effect is the same.
Close ?
FrontPage web/subweb boundaries serve
only a couple of purposes, logically.
They can be used for chunking content into
pieces so that one may work on a defined
piece and copy it for versioning without having
to work with and/or copy everything
and
They are used for permission boundaries, either
for browsing or authoring permissions,
Basically, whereever the designer is asking for
different NTFS permissions one could use a
FrontPage web/subweb to effect the permission
difference. The main impact is that one then has
changed the chunking - which should be only
a minor inconvenience to the author of the parent
web.
If the designer had said, take the 17 webs
./sitemain
./sitemain/group1
./sitemain/group2
etc
./sitemain/group16
and make them one, but set different NTFS
permissions on the folders
./sitemain/group1
./sitemain/group2
etc
./sitemain/group16
when you do this you destroy the ability of
the 16 departments to open and modify their
area as a FrontPage web or web folder.
If you leave them as separate webs, with
authorship of the main top web also having
authorship of every groupX subweb in addition
to the people in that department having authorship,
you have introduced the ability of the author of the
main web to accidently change the work of any of
the groupX departments. But they should be able
to work around that by good paractices - it would
be a human error thing.
And, if in each ./sitemain/groupX subweb there
was a folder ./sitemain/groupX/menuinfo that
the groupX authors kept updated for use by the
./sitemain web in its menu display - then all (assumed)
needs are covered (in fact, the ./sitemain author does
not really even need authorship on the ./sitemain/groupX
webs to do this)
Alternatively, you can leave the 17 webs
./sitemain
./sitemain/group1
./sitemain/group2
etc
./sitemain/group16
as they are, as separate FrontPage webs with
17 different authorships and then define
./sitemain/subinfo
./sitemain/subinfo/group1
etc
./sitemain/subinfo/group16
as 17 additional subwebs, with authorship over
all by the ./sitemain authors, and authorship also
in each ./sitemain/subinfo/groupX subweb given
also to the groupX authors.
I have many issues with how FrontPage goes about
seeming to manage NTFS settings. But, unless you
want to drill into some fairly ugly things you are best
off trying to work with FrontPage by using subwebs
as permission boundaries and letting it keep the grants
of authorship straight for you, rather than by starting
to micromanage at the NTFS level. Anyway, even if
you did directly modify at NTFS level successfully,
you may find that FrontPage (either on trigger by
someone using the Server Health function, or on its own
when new subsebs get defined) someday can and/or will
wipe out the NTFS modification you have made.
-- Roger Abell MS MVP (Security, Windows), MCDBA, MCSE both
- Next message: Roger Abell [MVP]: "Re: Password for spcific folder"
- Previous message: Robert Hawkins: "Digital Signature"
- In reply to: Jenny: "W2k and Front Page Security"
- Next in thread: Jenny: "Re: W2k and Front Page Security"
- Reply: Jenny: "Re: W2k and Front Page Security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
