![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Login Triggers Topic Summary: Created On: 1-Dec-2008 22:22 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I'm going to submit an enhancement request to Telelogic to implement the notion of a database login trigger. I invite comments on their characteristics in this thread.
I know that you can run startup DXL by putting files in: \lib\dxl\startupFiles, and can run startup DXL via command line options. Both these methods put control of the startup DXL in the hands of the users. We need to force the running of database wide DXL on startup such that the users cannot control or prevent it. I suggest you implement the notion of a Database Login trigger, with the following characteristics: [1] The trigger itself of course runs on the client, not the server. [2] Trigger 'event' is logging into the database. [3] Trigger 'scope' is always the database, 'project->all' as is the 'level'. [4] The trigger is stored in the database root folder. [5] A 'pre' trigger allows access to this User's own info, disallows access to the folder Hierarchy, and disallows access to the database properties including Users and Groups. set(trigPreConFail) means the user is logged out. [6] A 'post' trigger allows access to the entire database, Users, Projects etc. [7] These triggers run before any other '/Startup', command line switch DXL, or in fact before any other DXL loaded on the user's client. I'm pretty sure that means that these triggers will not be able to open modules visibly (since 'formal.dxl' has not yet run), and may mean that modules may not be opened at all with these triggers. [8] Database login triggers always run, ignoring the '-T' command line switch or any 'setTriggerState(false)' command in the user's Startup directory. Only the 'Administrator' can disable these triggers for herself with the '-T' switch. The body of the trigger will retain these capabilities: [1] The trigger can tell if the login is running in batch mode. [2] The trigger has access to all the environment variables, e.g. 'DOORSADDINS' and 'data'. [3] The trigger can log the user out, perhaps with exit_(). - Louie |
|
![]() |
|
![]() |
|
Agree completely Louie. We shouldn't have to rely on having dxl files on users machines to run login scripts. Or using command line switches in shortcuts. A database login trigger would simplify things immensely.
------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|
![]() |
|
![]() |
|
What if the trigger had a syntax or other logic error?
What if the user running the trigger doesn't have access to all projects? I recommend coming up with a use for such a trigger. Keep in mind that this also leaves the database very vunerable. For instance, what if I have been fired from my company, but before I go, I decide to implement a DOORS login trigger that consists of this line: exit_() I also would just love to start work at a client who has had an administrator create these triggers for years and years and years, and if I break one of them their entire system goes down... I see the potential value, but for all the value there is also just a lot of opportunities for disaster. ------------------------- Kevin Murphy http://www.baselinesinc.com |
|
![]() |
|
![]() |
|
I decide to implement a DOORS login trigger that consists of this line: exit_() So much potential there if someone makes you mad... ------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com Edited: 2-Dec-2008 at 17:57 by David Pechacek |
|
![]() |
|
![]() |
|
Problems with the trigger are resolved by the Administrator using the _T switch. That's why I gave that exception.
It doesn't matter if the user has access to all the Projects. DXL Triggers, Layouts, and AttrDXL have always been a very serious security consern, adding a database login trigger doesn't make it worse. Its just about as easy as having a database wide post-open module trigger (which, BTW, I use right now to simulate the login trigger; it gathers user client statistics once per day). Your arguments would be better applied to ALL triggers, not just this login trigger. EDIT: Instead of an exit_ trigger, why don't you just either purge all the projects, or write a trigger to do so. In our case, I'd like to gather Client statistics on database login. We'd also like to make sure the clients have a suitable Version before accessing the database. There are also DoD concerns about folks using the wrong license to access a new database. Other's can do clever things like download the latest DXL to the client machine. We can also do such things as turn debugging on for certain users. EDIT: and now that I think about it, there might as well be a database-logout trigger. That will help with max and average useage statistics. - Louie Edited: 2-Dec-2008 at 21:36 by Louie Landale |
|
![]() |
|
![]() |
|
I agree with Louie. Only the Administrator account should be able to apply that kind of trigger. And that's why you screen your employees before hiring them.
------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|
![]() |
|
![]() |
|
Suggestions so far:
[] Database logout Triggers [] Only the Administrator may define such triggers. |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Login Triggers
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.