SourceSafe confusion!?
Dan Williams
to setup Interdev to checkout and checkin my ASP & HTML files.
I've also setup a virtual directory to the local folder where my files are
checked out for testing purposes, and all seems to be ok.
However, what's to stop another developer (or even hacker) copying over or
editing my ASP files directly to the C:\inetpub\wwwroot folder?
Also, if a new ASP file is added manually, the file can be viewed on our
Intranet site, but is not added to the source control until a user adds it
themselves.
How can i stop people adding or amending files directly, without first
going via VSS?
--
Thanks in advance
Dan Williams
Chris Barber
directly to the files. It does however place the files as read-only when
checked in.
In terms of security you should set up NTFS domain security on the website
folder to disallow manual changes (eg. give the anonymous account read-only
and give web admins and authors read-write etc.).
Chris.
"Dan Williams" <dan_wi...@newcross-nursing.com> wrote in message
news:1xxm8gpr2zosb.3...@40tude.net...
Dan Williams
> You can't - Source Safe keeps your source safe but won't prevent changes
> directly to the files. It does however place the files as read-only when
> checked in.
> In terms of security you should set up NTFS domain security on the website
> folder to disallow manual changes (eg. give the anonymous account read-only
> and give web admins and authors read-write etc.).
>
> Chris.
So SourceSafe isn't the greatest tool to completely source control a web
site then?!
Isn't there a VSS Admin User i could setup that VSS can use to gain
permissions to write to my files, then i can disable access to everyone
else apart from that VSS user.
Having read this thread
http://groups.google.com/groups?q=vss+inetpub&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=056d01c36562%241a9d1b50%24a501280a%40phx.gbl&rnum=6
i would have thought this would be a valid requirement.
Might submit it to Microsoft as a product request/enhancement, assuming its
not already possible.
--
Thanks again
Dan Williams
Chris Barber
tool to allow multiple developers to work on a common project without
overwriting each other work all the time - also allows comparison of
multiple file versions to 'pull' forward changes to a common version.
Security is handled by the NTFS permissions on the directories themselves.
If you have issues with rogue developers changing files then you need to
review your domain security rights on the folders and files.
Under the hood, VSS uses a couple of generated user groups to determine the
rights of the developers in terms of allowing file changes. You can place a
specific developer in the group that allows changes but no new files to be
created or only have them in the group that allows read rights to the files
but not changes. Or there is the admin group that can change, delete and add
files and folders.
These groups are created when you apply FrontPage extensions to the site
that your are developing against.
Have a look at:
http://www.microsoft.com/technet/archive/default.asp?url=/technet/archive/office/office97/reskit/fp98serk/security.asp
Chris.
"Dan Williams" <dan_wi...@newcross-nursing.com> wrote in message
news:1dtg627okey4x$.9bfqofl9cr91.dlg@40tude.net...
Dan Williams
> Source safe is not used to control security for a website - it's merely a
> tool to allow multiple developers to work on a common project without
> overwriting each other work all the time - also allows comparison of
> multiple file versions to 'pull' forward changes to a common version.
> Security is handled by the NTFS permissions on the directories themselves.
> If you have issues with rogue developers changing files then you need to
> review your domain security rights on the folders and files.
> Under the hood, VSS uses a couple of generated user groups to determine the
> rights of the developers in terms of allowing file changes. You can place a
> specific developer in the group that allows changes but no new files to be
> created or only have them in the group that allows read rights to the files
> but not changes. Or there is the admin group that can change, delete and add
> files and folders.
> These groups are created when you apply FrontPage extensions to the site
> that your are developing against.
>
> Have a look at:
> http://www.microsoft.com/technet/archive/default.asp?url=/technet/archive/office/office97/reskit/fp98serk/security.asp
>
> Chris.
OK, cheers for that.
I'll look into it and play with my NTFS file permissions on my own
c:\inetpub\wwwroot folder.
Dan
Ewan McNab
Source safe does not 'keep your source safe' as you say. Any annoyed or
aggravated developer has full rights to delete your entire repository if
they can access it through VSS. One of the biggest problems with SourceSafe
is that it is based around file access. I.e. you require full access to the
repository folders (where your file history is maintained) to be able to use
VSS.
Regards
Ewan McNab
Quality Software Components Ltd
http://www.qsc.co.uk
"Chris Barber" <ch...@blue-canoe.co.uk.NOSPAM> wrote in message
news:OtcA%23Y8%23DHA...@tk2msftngp13.phx.gbl...
Chris Barber
from you a while back for both Isotrak and my own company now - Blue Canoe
Limited - mostly for VB development and now VB.NET.
It would seem that Dan's problem (as I read it) was not developers who were
already using Interdev to develop against the website but that of 'other'
unknown persons accessing the files across the LAN?
So, NTFS would seem to be the solution here? Its obvious to me that the
website source is changeable by other users in the domain who shouldn't have
rights to access or change those files.
BTW: TeamCoherence has been *very* stable now for at least 6 months - not
had a single issue with it recently! It's just a pity that using it with
Interdev would seem to be impossible (not your fault obviously - just the
way that IIS handles VSS integration on the local machine) .
Dan, can I suggest that you look at using a staging development website
(internal) and then a locked down site to publish to. In this manner you can
elect for the developers to tag the checked-in versions with a version
number and then deploy that (using a specific login I presume) to the live
location?
Chris.
"Ewan McNab" <Ew...@qsc.co.uk> wrote in message
news:0vOdnaLhzM8...@brightview.com...
Dan Williams
> Hi Chris
>
> Source safe does not 'keep your source safe' as you say. Any annoyed or
> aggravated developer has full rights to delete your entire repository if
> they can access it through VSS. One of the biggest problems with SourceSafe
> is that it is based around file access. I.e. you require full access to the
> repository folders (where your file history is maintained) to be able to use
> VSS.
>
> Regards
>
> Ewan McNab
> Quality Software Components Ltd
> http://www.qsc.co.uk
>
This was exactly the point that i was trying to get across. We have a
contracted consultant who works on our web site now and again, but he
continually develops on our live system, which obviously affects its usage.
We wanted to secure our server so as to force any developer to go through
VSS first, make amendments and test locally, then publish back to the
master server once we were happy with any updates.
We were hoping to have some form of version label and history automatically
updated on our web site, to make users aware of any latest changes. We
would also have the benefit of being able to roll back to previous
versions, and do file comparisons to see what changes our consultant had
made.
Ideally, our C:\inetpub\folder would be setup with only the one VSS System
user, so as to allow only the VSS service access to the files. This would
then prevent any unknown user or developer with direct access to the files,
but still allow VSS access.
Perhaps it is a product enhancement after all?!
Chris Barber
server and then only publish to the live server when fully tested.
VSS isn't required on the live server and you could restrict the file access
to just your own domain account for write / modify permissions.
Your developer should not be able to access the development code directory
directly anyway - just put a firewall on it [the server] or remove the drive
shares etc. preventing all but http: traffic thus forcing them to use
Interdev and front page server extensions to develop (exactly the same as
developing against a internet website).
Chris.
"Dan Williams" <dan_wi...@newcross-nursing.com> wrote in message
news:1eua5ckkh93th$.nlorhyfp14z$.dlg@40tude.net...