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

Impersonation

System

Howdy. I feel like I'm completely missing something so I hope somebody can help me out.

We have old Perl based CGI programs that use impersonation so that, for instance, when you "touch" a file, the timestamp is updated and it stays modified by the logged in person.

When I recreate this using a Java servlet, I can update the timestamp, but it then shows as SYSTEM (on Windows), instead of my ID.

I update the timestamp using setLastModified from one of the Java IO packages. I see there is a CSFile.getLastModifier(), but no setLastModifier.

So, am I missing something that would allow this to run as me and have the file show updated by me rather than system?

TIA

Craig

Find more posts tagged with

Comments

Crsb

What version of TeamSite are you running?

java code runs as iwui in 671 and higher, it looks like it is running as system in your machine.

see this thread

Migrateduser

Sorry, 6.7.2 SP2 on Windows

Migrateduser

What version of TeamSite are you running?

java code runs as iwui in 671 and higher, it looks like it is running as system in your machine.

see this thread

Interesting. I don't like ending up with another EA set, though. At least I got the "Modified By" set when I tried the iwextattr command.

Bjorn

Interesting. I don't like ending up with another EA set, though. At least I got the "Modified By" set when I tried the iwextattr command.

Craig - Maybe you can take a hybrid approach using the plain old Java you're already using and the CSSDK. The POJ part sets your last mod date. The CSSDK part ensures the last modifier is who you want it to be if it gets messed up.

Here is a crude, uncompiled example:


CSClient client; //you'll want to get this from the session, not from a factory
Date date = new Date();
for (String vpath : vpaths) {
     CSVPath vpath = new CSVPath(vpath).getPathNoServer();
     CSFile csFile = client.getFile(vpath);
     CSUser owner = csFile.getOwner();
     File jfile = new File("Y:" + vpath); //if windows, but you get the idea
     jfile.setLastModified(date.getTime());
     csFile.setOwner(owner);
}

It's a bit of a hack, I guess (the whole setting the owner to the current owner thing), but it should work (?).

The funny thing is, if I run code similar to above, BUT without any of the CSSDK stuff, the last modifer for me remains unchanged (at least as I view in ContentCenter).

Crsb

The funny thing is, if I run code similar to above, BUT without any of the CSSDK stuff, the last modifer for me remains unchanged (at least as I view in ContentCenter).

Yep

owner attr is different than "Modified by"... i couldn't find anything in CSSDK to set modified by, that is why i ended up adding an EA named "Modified by"... i explained the disadvantages of doing it this way in the other thread.

Bjorn

Yep owner attr is different than "Modified by"... i couldn't find anything in CSSDK to set modified by, that is why i ended up adding an EA named "Modified by"... i explained the disadvantages of doing it this way in the other thread.

I am not sure I see your point.

Of course owner and modified by are two different atts. If they were the same, why would you need two of them? Smiley Happy

The owner has nothing to do with it. It's just a "low-impact" way to make a change to a file without really changing anything. If you make a change -- any change -- to a file using the CSSDK, the last modifier is set to the CSUser that made the change.

Look at the code. It changes the owner to the same owner. It's just the fact that there's a change that the Modified By comes into play.

You could just as easily do something like:


boolean p = csFile.isPrivateToWorkarea();
csFile.setPrivateToWorkarea(p);

This issue really isn't "impersonation". It's who's doing what. If you use the CSSDK to change a file, even if the change doesn't really change it, the last modifier will be changed to the user who did the change.

ChangeSeriesLabelsOnBubbleChart.rptdesign

Crsb

I am not sure I see your point.
Of course owner and modified by are two different atts. If they were the same, why would you need two of them?

Maybe we are talking about 2 different things. i think this thread is about the issue of iwui user showing as the modified by when a teamsite user runs CSSDK functionality. so i explained one way to show the actual teamsite user taking action as the modified by not iwui.

If you make a change -- any change -- to a file using the CSSDK, the last modifier is set to the CSUser that made the change.


CSClient client; //you'll want to get this from the session, not from a factory
Date date = new Date();
for (String vpath : vpaths) {
     CSVPath vpath = new CSVPath(vpath).getPathNoServer();
     CSFile csFile = client.getFile(vpath);
     CSUser owner = csFile.getOwner();
     File jfile = new File("Y:" + vpath); //if windows, but you get the idea
     jfile.setLastModified(date.getTime());
     csFile.setOwner(owner);
}

As you said, that code will set the owner of the csFile to whatever CSUser is in the session (based on your comment). So my answer was that it still doesnt resolve the issue. the modified by will still show up in the UI as iwui.

The CSSDK part ensures the last modifier is who you want it to be if it gets messed up.

This issue really isn't "impersonation". It's who's doing what. If you use the CSSDK to change a file, even if the change doesn't really change it, the last modifier will be changed to the user who did the change.

i wish that was true, my experience with using CSSDK is that it runs as iwui whether i invoke it from a WF or from custom action/tab in TeamSite ( TS671 and 672)... every time i print "System.getProperty("user.name")", i get iwui. which is different than the actual user running the workflow( CSClient.getCurrentUser()) or taking action in teamsite (httpRequest.getAttribute(csclient attribute)).
if you think this is not true, then i am probably doing something wrong or my teamsite is missing something. and i would love to figure out what i am missing.

columnsbasedonparameters1.rptdesign

Bjorn

i wish that was true, my experience with using CSSDK is that it runs as iwui whether i invoke it from a WF or from custom action/tab in TeamSite ( TS671 and 672)... every time i print "System.getProperty("user.name")", i get iwui. which is different than the actual user running the workflow( CSClient.getCurrentUser()) or taking action in teamsite (httpRequest.getAttribute(csclient attribute)).
if you think this is not true, then i am probably doing something wrong or my teamsite is missing something. and i would love to figure out what i am missing.

Interesting. I actually think it IS true, only b/c what you describe isn't my experience. If I get a CSClient object and modify a file using the CSSDK, the CSUser to whom the CSClient "belongs" is the one that shows as Modified By. This matches what would seem to be the expected behavior where actions done under a CSClient would be "credited" to the user on that CSClient.

Are you saying if you write a simple servlet (and map it appropriately to IW's authentication filter in web.xml) and get a CSClient object from the request, and then use that CSClient object as the basis for something like modifying a file, then the modified by always shows iwui (or SYSTEM, etc.) in ContentCenter? That doesn't make any sense -- anytime you'd use the CSSDK it would mess up your files.

The only way that scenario would make sense is when it's confusing about from where the CSClient actually comes, like:
- in a workflow task
- or if you're using a CSFactory and "getCurrentUser()" -- which is terribly named because it doesn't do what its name makes it seems like it would do - or if you had a servlet that simply used plain old java to modify a file.
But not through the CSSDK.

I'd be interested to see some code where this is happening for you just so I could try it in my environment.

Also, I'm not sure I followed what you meant with the System.getProperty("user.name"). Of course this would always be "iw.ui", right? That's the user under which the servlet engine (iwservletd) is running.

Crsb

....The only way that scenario would make sense is when it's confusing about from where the CSClient actually comes, like:
- in a workflow task
- or if you're using a CSFactory and "getCurrentUser()" -- which is terribly named because it doesn't do what its name makes it seems like it would do - or if you had a servlet that simply used plain old java to modify a file.
But not through the CSSDK.

I agree with you now and your reply actually identified a mistake i made. i defined any custom java code that has some CSSDK as CSSDK code/functionality. where most of the code where iwui shows as the modified by is actually plain java code since CSSDK doesn't have all java APIs.
From your reply, i understand that if you do something like CSClient.somefile.someAction on a file, then it shows the modified by as the CSUser behind the csclient. And if you take any action on the file without somehow using CSClient, then it shows up as iwui. correct?

Also, I'm not sure I followed what you meant with the System.getProperty("user.name"). Of course this would always be "iw.ui", right? That's the user under which the servlet engine (iwservletd) is running.

yes, that is what i meant. if you run plain java code from a workflow or TeamSite custom action, it runs as iwui.

now is that impersonation issue?

how would you get around this to show the actual user invoked the code as the modified by?

just in case of the answer is "CSSDK", well, can you do everything with CSSDK?

Bjorn

now is that impersonation issue?

how would you get around this to show the actual user invoked the code as the modified by?

just in case of the answer is "CSSDK", well, can you do everything with CSSDK?

I guess this is what's annoying about the CSSDK. There are gaps between getters and setters. It'd be nice if (as much as possible) they had a set method for every get method. So you could do things exclusively via the CSSDK that you can't right now, like set the last modified date, last modifier, etc.

But you can still accomplish this (sort of), by complementing any block of code that you write that modifies a file via regular old java, to do a "dummy" modification via the CSSDK to kludge in the right user after it's been set to SYSTEM or whatever by the plain java code. This will add some bloat and confusion to your code, but it gets you what you want, I suppose.