This is very true. We have a few integration service account where the those accounts should never login to any clients except web services. It would be nice to have a way of listing allowed client-types in the User record and having AR System enforce it natively.
I haven't looked yet, does MyIT have its own $CLIENT-TYPE$? If it doesn't maybe it should. Jason On Fri, Sep 6, 2013 at 1:34 PM, Pierson, Shawn < [email protected]> wrote: > I could see this being useful for automation as well. For example, you > create an account to integrate with a monitoring tool that uses the Remedy > API to create Incidents, but you don't want the owner of that account to > log in and manually use Remedy with that account. > > If you wanted to do a "mean" approach, you could probably just create an > Active Link that is triggered On Display whenever they log in to the Remedy > Home Page that checks for $USER$ = "usernametoblock" and do a Run Process > of PERFORM-ACTION-OPEN-URL " > http://yourremedyserver/arsys/shared/logout.jsp"; > > Thanks, > > Shawn Pierson > Remedy Developer | Energy Transfer > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of SUBSCRIBE arslist Aditya Sharma > Sent: Friday, September 06, 2013 3:30 PM > To: [email protected] > Subject: Re: Prevent MT Login > > Client tool I do not only refer to User Tool.. It can be dev studio, spoon > client, import tool etc.. this solution if possible through a non-workflow > mechanism can help in preventing unnecessary login through generic accounts > over web URL which is available over internet.. Client tools access we can > restrict through VPN or other ways. If there can be a mechanism to > blacklist some accounts to login through web; This can be one of the major > security requirements to make sure Admin accounts are not misused. > > Sent from my BlackBerry(r) smartphone from !DEA > > -----Original Message----- > From: Joe D'Souza <[email protected]> > Sender: "Action Request System discussion list(ARSList)" < > [email protected]> > Date: Fri, 6 Sep 2013 16:02:47 > To: <[email protected]> > Reply-To: [email protected] > Subject: Re: Prevent MT Login > > PERFORM-APPLICATION-LOGOUT from the home page or any other page that the > user might have access too if the $CLIEMT-TYPE$ = 9.. > > Why would you have such a requirement though when the future versions does > not support access through the native User client? > > This is a workflow mechanism - it will be impossible to do it with a non > workflow mechanism. Unless you are free to employ a security guard to stand > besides that employee and beat the crap out of him if he tries to log in > through the mid tier.. That would be a non workflow mechanism :) - primitive > - but will work.. :) > > Joe > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of SUBSCRIBE arslist Aditya Sharma > Sent: Friday, September 06, 2013 3:59 PM > To: [email protected] > Subject: Prevent MT Login > > > Hi Listers, > > I have a requirement to prevent a particular user to be able login through > mid tier but same user should be able to login to client tools. Has anyone > implemented such requirement? What can be the best way to achieve this? > > Specifically looking for a non-workflow mechanism. > > Regards, > Aditya > Sent from my BlackBerryR smartphone from !DEA > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the > Answers Are, and have been for 20 years" > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the > Answers Are, and have been for 20 years" > > Private and confidential as detailed here: > http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot > access the link, please e-mail sender. > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
