nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

submit.cfg

Ottawa_IWOV

All,

TS 5.5.2 - W2K

I am having a heck of a time setting file permissions with submit.cfg.

Everyone needs to be part of the Teamsite Web Preview group (in order to virtualize properly in TS - please tell me if I am wrong), and this group, by default, has full control for all members. I am trying to change this to read only on certain files in a workarea (ie. HTML), and the filter picks up Teamsite Web Preview as RX:

\.html$
{
owner=Administrator
group=cesg_wg-gt_seec
changeaccess={everyone:rx, john:all, "teamsite web preview:rx"}
}

When an .html file is submitted to STAGING and I check the file permissions (in the WORKAREA), it says that Teamsite Web Preview is RX, but when I check the ACL on the file on Y:/ it states that Teamsite Web PReview has full control.

All all users can edit this file in the WORKAREA.

I am a little confused...

Regards,

Lucas Cochrane
(613) 786-7528
lcochrane@dc.com

Find more posts tagged with

Comments

Migrateduser

First, nobody should be a member of the web preview group except the TSIMP_hostname user account. Let's review what this group and user are for:

1. TS creates a user account, TSIMP_hostname, and a webserver group, "TeamSite Web Preview", when it installs on a W2K/IIS server, and it puts the TSIMP_hostname account into the group.

2. TS gives FULL CONTROL access (AKA ownership) to the webserver group.

3. TS makes the anonymous access account for the IW-Mount IIS webserver "TSIMP_hostname"

4. When you click on a file name in the TS GUI, this sends an anonymous read request to the IIS IW-Mount web server. Since it's anonymous, the TSIMP_hostname account is used as the accessor.

5. Since TSIMP_hostname is in the webserver group, the preview is allowed. At no time does it matter what your actual user account is.

Putting other people in the webserver group will open a security hole.

The TS server handles the webserver group permissions internally--you cannot change the ACEs for this group in the IFS, using submit.cfg or any other means. It will always be "FULL CONTROL".

Now, as for submit.cfg: On Windows, the "group" and "owner" actions are NOT supported. Only ChangeAccess and SetAccess are.

You need to use iwtestcfg to make sure your submit.cfg file is actually working--read about it in the admin guide.

Also, make sure you call iwreset each time you make any change to submit.cfg.

bw

Also: when referring to users or groups in SetAccess or ChangeAccess, make sure you use the full syntax, ie, "DOMAIN\john", not just "john".

Bob Walden [bob.walden@interwoven.com]
Interwoven Education Group
IM: Yahoo, MSN bob_walden

Ottawa_IWOV

Thanks a lot for clarifying that for me. It also makes complete sense.

Might I be able to throw another question your way. If I map the Y:/ drive so users can have access to create files and directories in WORKAREAS, does the submit filter play a part in this role?

Any thoughts would well received

Thanks.

Adam Stoller

submit.cfg as the name implies only pertains to actions taken when *submitting* files - therefore having mapped drives makes no difference.

--fish
(Interwoven, Curriculum Development)

iwovGraduate

The submit filter comes into play when you submit the files to STAGING. I don't see how mounting Y: has anything to do with submit filter. Maybe you can clarify what you are asking ?

andrew_yeo

juz want to understand further,

is it standard practise to have TeamSite Web Preview "enabled" in the iw.cfg in a typical TeamSite setup. Or do we juz leave it out as it comes when TS is being installed??? 'cos when we have "TeamSite Web Preview" disabled, the respective users from their workarea will be ABLE to Browse, Create Dir in other workareas as well BUT not able to submit though...which i thought shouldn't be the case...

YET, when we have "TeamSite Web Preview" enabled... the users of respective WAs will not be able to "see" other's WA but will encounter problems in the STAGING where some contents becomes "N/A" thereby unable to preview the entire site.... really weird...or maybe i'm juz too dumb to understand the whole concept of TS....

andrew_yeo

does this makes a "workable" submit.cfg for Windows

CASE-SENSITIVE = NO

RULES
{
. # any workarea
{
# all files
.*
{
# setaccess = {everyone:R}
setaccess = {everyone:FULL}
# changeaccess = {everyone:RX}
}
}
}

and by having this submit.cfg, does it also mean that whatever that is submitted to the STAGING will inherit these permissions?

tks.

Adam Stoller

I believe that submit.cfg will turn on all access rights for Everyone (both figuratively and literally) - but if you're going to do this, there's no point in defining a webserver_group in your iw.cfg - because that would be the same thing.

The purpose of the webserver_group and submit.cfg is to allow you to restrict access to files and folders within workareas according to who you believe should have access. If you do not care about such restrictions don't bother to use either.

Also - if you want to verify the results of the settings in the submit.cfg file - take a look at the iwtestcfg CLT (remember, in order to see your changes to submit.cfg take effect, you need to do an iwreset)

Okay?

--fish
(Interwoven, Curriculum Development)

Pallete_Labels.dcpackage

Migrateduser

The webserver group's purpose is to enable access via smart context QA--ie, viewing a file through the TS GUI.

submit.cfg, on the other hand, is far more powerful. It's purpose is to define your asset access policies for your entire backing store. Using it, you can enforce rules like "all programmers have read/wite access to .jsp files, but others can only read and execute" or "only members of the hr group can access the /corporate/hr directory."

If used correctly, the webserver group will have no impact on access to file assets via the IFS/Y: drive, nor should it determine who can see, read or change files. It's only purpose is to control anonymous access to the /iw-mount virtual web server, used for preview and smart context QA.

Bob Walden [bob.walden@interwoven.com]
Interwoven Education Group
IM: Yahoo, MSN bob_walden

CC1.PNG

CC2.PNG