Jump to content


Photo
- - - - -

Keeping track of users...


21 replies to this topic

#16 Bob Filipiak

Bob Filipiak

    Expert

  • Members
  • PipPipPipPip
  • 133 posts
  • Gender:Male

Posted 03 June 2004 - 09:55 PM

. . .

And if you really want to be a schmuck, have the system print out an order form for those additional licenses.

Bob Filipiak

#17 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 03 June 2004 - 10:27 PM

Bob,

I was going to say, skip the order form, hit the credit card automatically....

But, in all seriousness, there is a good business case creating a crude audit of every time too many people tried to log in. This way, you - or the end client, can periodically review how often they are bumping up against their maximum # of licenses.

It's one thing to tell a client that they should think about getting more licenses and another to demonstrate that on average, four times a day, people are not being able to log in and get their work done....

Regards,

Joseph

#18 Bob Filipiak

Bob Filipiak

    Expert

  • Members
  • PipPipPipPip
  • 133 posts
  • Gender:Male

Posted 04 June 2004 - 05:20 PM

Joseph,

A long time ago, I wrote some code to log in real time user logins. Somehow things were getting changed, but management could not figure out who is responsible.

Thus, management got a log file that had a time stamp entry of when someone logged in, and which terminal number they used. They also got a time stamp entry of when that person logged out.

It was interesting to find that the most used terminal number for out of workweek entries was the one the modem was connected to. So, a chnge in allowed terminal numbers for specific users put an end to the unauthorized changes.

In fact, it would not be a bad idea to an app developer to include this kind of functionality from the start.

BTW - I like the automatic credit card charge. I feel, that software should be rented on a "per use" basis - after all MAXIMUM profit for the developer!!!!!! Just think, user logs in, credit card get charged, and upon approval, the user is given access to the system. Not a bad profit center.

Bob Filipiak

#19 Rick Young

Rick Young

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 265 posts
  • Gender:Male
  • Location:Guelph, Canada

Posted 04 June 2004 - 05:35 PM

software rental - lucky no-one has mentioned anything including the word "portal" in conjunction with say, a .xxx domain. :-"

#20 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 04 June 2004 - 06:45 PM

Rick,

No self-respecting ProIV programmer would do anything with an XXX portal - The legacy support for character based access is far too much work.

I can't speak for Concerto programmers though... :unsure:

Joseph

#21 gkwalton

gkwalton

    Expert

  • Members
  • PipPipPipPip
  • 106 posts
  • Gender:Male

Posted 04 June 2004 - 07:29 PM

I have one more issue that has come up.

All of my users sign on with the automatic login option set in the GUI client. Is there a way to have the "echo" messages appear without having the telnet window open? After the login fails the telnet window will appear and the message will be there but it takes too long.

Thanks,
George.

#22 Joseph Bove

Joseph Bove

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 756 posts
  • Gender:Male
  • Location:Ramsey, United States

Posted 04 June 2004 - 09:55 PM

George,

You can change the amount of time until the telnet window comes up. This is done by editing the little a line in the PIV. The number following it is in milliseconds.

a10000 means that the telnet window opens in 10 seconds.
a20000 would mean 20.

Another option: We use this at over 90% of our Unix sites. Have all your application users automatically login to Unix as the same user. This simplifies PIV's tremendously, because you only have to set it up once and one PIV is valid for all application users at a single client site.

Of course, you'll want the default user to be directed to an application based login screen with the appropriate security features. This setup cuts the task of user maintenance in half as you only have to maintain users at the application level and not both the app and OS level.

hth,

Joseph



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users