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 <[email protected]> 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 <[email protected]> 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: > [email protected]] *On Behalf Of *Tauf Chowdhury > *Sent:* Friday, September 06, 2013 4:23 PM > *To:* [email protected] > *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" <[email protected]> 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:[email protected] <[email protected]>] *On Behalf Of *Jason > Miller > *Sent:* Friday, September 06, 2013 4:19 PM > *To:* [email protected] > *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 <[email protected]> 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: > [email protected]] *On Behalf Of *Jason Miller > *Sent:* Friday, September 06, 2013 4:11 PM > *To:* [email protected] > *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 <[email protected]> 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:[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" > > > > _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_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
