Good point. I had a different idea of redirecting the user to another URL altogether but thought to myself, "That's not appropriate for work" so I changed it before I sent the email.
Thanks, Shawn Pierson Remedy Developer | Energy Transfer -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe D'Souza Sent: Friday, September 06, 2013 3:43 PM To: [email protected] Subject: Re: Prevent MT Login Perform-action-exit-app is the better to use than just calling the logout page using the open url page.. I'm not sure it will actually do a logout by opening the logout page that way.. Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pierson, Shawn Sent: Friday, September 06, 2013 4:34 PM To: [email protected] Subject: Re: Prevent MT Login 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" 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"
