Public Access through Shared Account

Judi_Minnerly_(EAFB-Minnerly_(Delete)_2184028)

I'm trying to open livelink to the public by passing a shared user name and password in the URL like this:/livelink/livelink.exe?func=LL.login&NextURL=%2Flivelink%2Flivelink%2Eexe%3Ffunc%3Dll%26objtype%3D141%26objaction%3Dbrowse&username=public&password=anonymousTo prevent access to the personal workspace, change password, and other options I removed the Goto menu from the enterprise folder hierarchy by modifying the 'commonheader.html' file. But I cannot remove the Goto Menu from HTML rendered documents (viewed documents).Access to Change Agents functionality is also a problem.Does anyone have any insights on opening Livelink to the public such that the number of potential hacker exploits are minimized.Thanks!Eric.Williams@Edwards.AF.Mil

Find more posts tagged with

Comments

Application_Services_FUJITSU_(fuji_ware05_-_(delet

You don't have to change the html layout. Even when removing some item out of the HTML you can access the data by typing the url directly...You should disable the wanted functionalities in the module itself (oscript)....Kind regardsJohan RaedemaekerswITch AsBuiltmailto:jraedemaeker@switch.be

Jose_Garcia

This won't solve all your problems but for what its worth a simple way to prevent the user from accessing the Personal workspace is to call up the account in Users & Groups (while logged in as Admin). Browse their Personal Workspace. Click the "info" icon for that Workspace and from there remove all their Permissions to that space.After that if someone using that account tries to access the Personal Workspace they'll get the following message.Livelink Error: Error browsing the specified object. [Could not access a Personal Volume.]

Henk_Koster

Wonder to know if there is any new functionality in Livelink 9 that allows to create a user without Personal Workspace.Thanks in advance for any reply.Martin.m.farfan@nam.nl

eLink User

Message from magnus <<A HREF="mailto:magnus@ids.se">magnus@ids.se> via eLink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">eLink

What is the problem ?!?!?

You can always take away the access rights to the personal workspace......

Regards

magnus@ids.se

----- Original Message -----

From: eLink Discussion: Development Discussion

To: eLink Recipient

Sent: Friday, October 05, 2001 5:28 PM

Subject: Any improvement in Livelink 9 ?

Any improvement in Livelink 9 ? Posted by NAMUser3 (NAM, Functional) on 10/05/2001 11:27 AM
In reply to: Public Access through Shared Account Posted by EAFB-DanRobles (Robles, Dan A) on 05/23/2000 03:06 PM

Wonder to know if there is any new functionality in Livelink 9 that allows to create a user without Personal Workspace.

Thanks in advance for any reply.

Martin.

m.farfan@nam.nl

Karl-Heinz_Jakob_(kjakob_(Delete)_3464807)

Is it possible to do so for all users by a LiveReport? I want to give all users only Read Access to their Personal Workspaces.Any hints are welcome

Donna Nalls

Hello,yes, it is possible; however, not recommended to make these kinds of changes directly in the database - better to use an OScript or LAPI routine to loop through all current Workspaces. You can then add a user callback to modify any new users that you create.If you choose to move forward with the idea, you can do the following, here are some suggestions - PLEASE TEST THOROUGHLY: 1) Update the DTree table - permissions bitmask for the ownerupdate dtree set upermissions = 36995 where subtype = 142You might want to exclude Admin's Workspace (check for the dataid for this - it is probably 2003 if this was v9 install)update dtree set upermissions = 36995 where subtype = 142 and dataid != 20032) Update DTreeAcl table - permissions bitmask for the owner.update dtreeacl set permissions = 36995 where dataid in (select dataid from dtree where subtype = 142)and acltype = 1 and rightid = dataidI have not tested this information thoroughly, and, once again, recommend writing an OScript or LAPI routine to accomplish this task...AND, AS ALWAYS...PLEASE TEST THOROUGHLY!! PLEASE TEST THOROUGHLY!!Regards,Donna

Greg_Griffiths_(greggriffiths_-_(deleted))

while this does give you read only access to the users PW, it does not stop them from going to their Assignments list etc - either via the menu or directly - you may want to lock these down as well.

Donna Nalls

why do you presume that one action mandates the other? Is it not conceivable that you would want to prohibit users from using their Personal Workspace, but they still may be participants in a workflow or have a task assigned to them?If it is the desire to lockdown Assignments or other areas of the tool, I would suggest an OScript callback that would validate a list of areas that is locked down against a user role - to allow flexibility to expand as needed for areas of the tool and restricted users.

Greg_Griffiths_(greggriffiths_-_(deleted))

Donna is completely correct that the first action may not always lead to the second one, but in some cases it may do, apologies if it came across as a 'must' - just that in the cases I've looked at it was, but I recognise that for others it may not be.