Yes you trap the login in function dologin (I'm not sure of the function name) which is called when you submit the login and do a simple check on the username and if it matches, you exit the function.
I guess it would be hardcoded or you could use jquery to query a distant page to check the username. I guess there could be a way to gather a js code from this page as well and eval it but in the end it wouldn't resist a lot of time... Mobilis in Mobile -------- Message d'origine -------- De : Jason Miller <jason.mil...@gmail.com> Date : 10/09/2013 0:09 (GMT+01:00) A : arslist@ARSLIST.ORG Objet : Re: OT: Prevent MT Login ** I think the javascript solution should be a last resort kind of thing. I am glad a few people have pointed out Disable-Client-Operations which I am hoping will work instead of javascript changes for the reasons mentioned. Although for the sake of discussion I am still trying to figure out how this would work using javascript. Do you hard code the username in the JS? Do you create a database table to store the limited users and they create JS to query that upon login? All of the ways I can think of do not scale well, add vulnerabilities and extra development/maintenance effort. Jason On Fri, Sep 6, 2013 at 1:41 PM, laurent matheo <lm...@me.com> wrote: ** Yep, and the other problem with javascript on login.jsp is that if he knows the "login trick" giving credentials in the url the "sorry pal I got you" trap in login.jsp wouldn't work. In this case you could alter the LoginServlet instead I guess, though that would mean quite some work... Another solution would be to create a keylogger that would detect what keystrokes he hits and automatically delete according text. (and send him back a 110V jolt through his keyboard). On 06 Sep, 2013,at 10:29 PM, Joe D'Souza <jdso...@shyle.net> wrote: True.. java scripts written on the login page are subject to break when you update a patch unless you manually fix the page again. Workflow approach will not have that limitation.. Joe From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Tauf Chowdhury Sent: Friday, September 06, 2013 4:23 PM To: arslist@ARSLIST.ORG Subject: Re: OT: Prevent MT Login It would Ken. It's up to the poster. I would think writing workflow is easier then getting JavaScript in so who knows. Sent from my iPhone On Sep 6, 2013, at 4:20 PM, "Cecil, Ken" <kce...@hubbell.com> wrote: ** My suggestion was neither. Use javascript to catch the user id in the submit of the midtier login.jsp page and redirect that user to an error page. Ken. Would it not work? Ken. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Friday, September 06, 2013 4:19 PM To: arslist@ARSLIST.ORG Subject: Re: OT: Prevent MT Login ** I agree it it is either workflow or a BMC provided option baked into the product. On Fri, Sep 6, 2013 at 1:17 PM, Joe D'Souza <jdso...@shyle.net> wrote: ** Na.. those were beautiful! I wish I get to see them at least once again before I don’t have to travel to Alaska no more.. My next trip is scheduled to be my last.. I like the DNS spoofing idea from Tauf – only that these days most IT employees are smart enough to realize what’s happening, and if they have access to edit their own host file, could revert it back. I really don’t think there is a fool proof non workflow mechanism that can’t get in legal trouble to do what needs to be done. Workflow seems to be the safest bet. Joe From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Friday, September 06, 2013 4:11 PM To: arslist@ARSLIST.ORG Subject: Re: Prevent MT Login ** Wow Joe, wow 8-) I wonder if there is some radiation coming off the Aurora and soaking into your brain... On Fri, Sep 6, 2013 at 1:02 PM, Joe D'Souza <jdso...@shyle.net> wrote: 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:arslist@ARSLIST.ORG] On Behalf Of SUBSCRIBE arslist Aditya Sharma Sent: Friday, September 06, 2013 3:59 PM To: arslist@ARSLIST.ORG 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" _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Confidentiality Requirement: This communication, including any attachment(s), may contain confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that you have received this communication in error and any unauthorized review, use, disclosure, dissemination, distribution or copying of it or its contents is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone or e-mail and destroy all copies of this communication and any attachments. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ ** _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "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"
