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; } } }

Workarea Security Issue

RocknRoll

Hi All,

I am totally stumped on workarea security issue. Any guidance would be really appreciated..

Here's a scenario:-

1) Currently I have one workarea called News with in branch called Dow which consist of 5 DCTs and its generated pages. It is access by TS group called News_Editor.

2) Now Client prefer to have 2 more workarea (Publisher and Designer) built with in same branch called Dow. This workarea should contain only certain DCT and generated pages depending on news information and same time this workarea will be access by different TS groups called News_Publisher and News_Designer.

For eg – one News Dept workarea shouldn’t be able to see other News Dept workarea.

3) Steps Taken Already

1. Created New Workarea called Publisher
2. It is Shared By News_Publisher Group
3. Using Copy To command copied DCT and interested generated pages from News workarea.
4. Modified iw.cfg to ensure branch and workarea security is turned on.
5. Performed iwreset -a
6. Modified submit.cfg to following:-

/default/main/dow/WORKAREA/*
{
[^/]$ # all other files
{
group="DOW\\news"
setaccess = {"DOW\\news:rwxd"}
}
/$ # all directories
{
group="DOW\\news"
setaccess = {"DOW\\news:rwxd"}
}
}

7. Performed iwreset
8. Logout
9. Logon to TS on browser via testuser account that was created for News_Publisher
9. I see selected DCT but when I click on New form I get error stating unable to read //….//news/datacapture.cfg due to a security issue. Please contact your system administrator.
10. Any Suggestions on what am I doing wrong?

Environment: TS 6.5 SP2, Win 2003 Std

Find more posts tagged with

Comments

Lex

The "Copy To..." function doesn't set the correct permissions on the files copied. We ran into this exact situation - the group you are using for sharing the workarea needs read access on the DCTs. There are two ways to accomplish this that I know of (there may be others): use the file system to go in and set the permissions (you can do this at the workarea folder level and just have the permissions on that directory applied to all child objects) or (this is what we do) store the templatedata directory you would like to copy from in a file share and simply import it into the workareas. Importing will properly set the permissions on all the objects. I'm not sure if the permissions issue with "Copy To..." is a bug or if it's by design.

RocknRoll

Lex - I tried what you suggested. Still same issue.

Another thing I noticed that even though I have defined submit.cfg but even after submitting DCT and content to staging. My defined configuration doesn't appear. It remains original one.

Lastly, I noticed that for example datacapture.cfg or tpl or even generated pages don't have my defined group sharing access it is blank. Is that normal?

Thank you for all the help in advanced.

Adam Stoller

Here's a scenario:-

1) Currently I have one workarea called News with in branch called Dow which consist of 5 DCTs and its generated pages. It is access by TS group called News_Editor.

2) Now Client prefer to have 2 more workarea (Publisher and Designer) built with in same branch called Dow. This workarea should contain only certain DCT and generated pages depending on news information and same time this workarea will be access by different TS groups called News_Publisher and News_Designer.

Alarms should be going off in your head right now. Workareas are intended to be views of the entire branch (plus modifications) - they are not supposed to maintain different files - and attempts to do so will generally lead to misery and failure.

I believe there has already been a response with respect to the rest of the issue described.

nipper

Alarms should be going off in your head right now. Workareas are intended to be views of the entire branch (plus modifications) - they are not supposed to maintain different files - and attempts to do so will generally lead to misery and failure.

I believe there has already been a response with respect to the rest of the issue described.

Make those a subbranch, not different workareas.

I have seen people do this before (with workareas). The results have been bad.

Or do it, put a lot of money for an expensive consultant to come in and fix it later on. I have made quite a lot of money that way. When things are so totally screwed up no one ever argues about your daily rate. :rolleyes:

RocknRoll

Alarms should be going off in your head right now. Workareas are intended to be views of the entire branch (plus modifications) - they are not supposed to maintain different files - and attempts to do so will generally lead to misery and failure.

I believe there has already been a response with respect to the rest of the issue described.

Ghoti - I agree with you 100% on exactly what you say. So, does that mean for security access workarea isn't best recommended method?

RocknRoll

Make those a subbranch, not different workareas.

I have seen people do this before (with workareas). The results have been bad.

Or do it, put a lot of money for an expensive consultant to come in and fix it later on. I have made quite a lot of money that way. When things are so totally screwed up no one ever argues about your daily rate. :rolleyes:

We had recommended subbranch. Client came back staying issue with licensing. Isn't that true?

Adam Stoller

Ghoti - I agree with you 100% on exactly what you say. So, does that mean for security access workarea isn't best recommended method?

content and access are two different things - I'm not sure what the access problems are as I'm not looking at your environment (though I could make some guesses... I don't feel like doing so)

nipper

We had recommended subbranch. Client came back staying issue with licensing. Isn't that true?

Could be, if they purchased the small server that is limited to 10 branches.

How many are you using ? Do you have empty branches (i.e. placeholders) ? You may be able to get approval to go over if you are only using 10 active branches.

The main point is that if you try to do what you said you wanted to, you will break things very badly and my rate will be $5000 a day to fix it. Smiley Very Happy

, Adam will be available at $4,995 and I imagine you can get Bo to help for a mere $4,990 per day.

Adam Stoller

We had recommended subbranch. Client came back staying issue with licensing. Isn't that true?

I believe the customer has been an Interwoven customer for some time - yes? as such, the restriction on number of branches (which i think is ludicrous anyway) shouldn't apply to them - but if-in-doubt - get the Interwoven Rep's involved...

RocknRoll

I believe the customer has been an Interwoven customer for some time - yes? as such, the restriction on number of branches (which i think is ludicrous anyway) shouldn't apply to them - but if-in-doubt - get the Interwoven Rep's involved...

Hi Ghoti - As being expert :-) would you not recommend to use different workareas with different access with in single branch just to avoid headache?

Can this workarea access be handle differently in 6.7.1? I read through administration guide and it seems similar to 6.5.

Your guidance would be appreciated. Thank you.

nipper

I believe the customer has been an Interwoven customer for some time - yes? as such, the restriction on number of branches (which i think is ludicrous anyway) shouldn't apply to them - but if-in-doubt - get the Interwoven Rep's involved...

No question about talking to the sales critter. They can tell you for certain. However I certain do understand and agree with the lower price point server and limited number of branches. 10 is the lowest number they sell and should be enough for a lot of small to medium implementations.

Adam Stoller

Hi Ghoti - As being expert :-) would you not recommend to use different workareas with different access with in single branch just to avoid headache?

Can this workarea access be handle differently in 6.7.1? I read through administration guide and it seems similar to 6.5.

Your guidance would be appreciated. Thank you.

As I said before - having different access rights to the workareas on a single branch is one thing (and supported), having different access rights on the same file in different workareas on the same branch, or having different files maintained in different workareas on the same branch is another thing (and unsupported, and likely to cause LOTS of problems down the road).

This is not something which has changed (as far as I know) between 3.0 and 6.7.1