Hi Jason :) I guess you were thinking about "arsystem.inclusion_goto_urls": https://communities.bmc.com/thread/95765 But it seems it only works for the logout servlet if you do a customize button and you are using "goto" (?): https://docs.bmc.com/docs/display/public/ars81/Creating+a+login+or+logout+form+element+button
The problem is that the "login.jsp" page is hardcoded in "DefaultAuthenticator.class" from "MidTier.jar". I°) first solution: Soooooo, I used a hexa editor to change the value from "login.jsp" to "klatu.jsp". My login page is "klatu.jsp" and when the login fails, it's redirected to "klatu.jsp" so it seems to work in this case :) Then the problem is that you can't really put whatever you want in url because of course the .class is byte coded, so if you put "klatuishere.jsp" it's too long. One way I did it was I had a page "klatuishere.jsp" which is my login page. Though in the class file, I just put "klatu.jsp" to respect the string length. In klatu.jsp, I have a simple redirect to "klatuishere.jsp" :) It seems to work. The problem is that it means that of course the "klatu.jsp" page will be called for all failed login, and maybe you don't want this since it replaces one hardcoded value by another... II°) Other way: Let's say you have two pages, one "login_normal.jsp" for standard users and "klatuishere.jsp" for special users. When someone uses the "special" "klatuishere.jsp", you generate a special cookie and you store the information "klatu" in it. If the user user "login_normal.jsp", just store "login" inside the cookie. After the failed login, you are sent back to "login.jsp", though in this file you modify it to read the content of the cookie. If inside the cookie you see "klatu", you redirect to "klatuishere.jsp", else to "login_normal.jsp". It seems to be working, I made a test. Though I made quite some screencaptures and a video so well... If you want how it went, please check this url, you have the explanation of both methods, the source codes and the video that shows the demo: https://communities.bmc.com/docs/DOC-32806 On 28 Aug, 2014,at 11:52 PM, Jason Miller <jason.mil...@gmail.com> wrote:
** It isn't Remedy workflow objects that handle this. It is coded into Mid Tier. Purely guessing but you could likely find the .jsp or .jsfile that has the logic and path you could change. I am figuring you have customer that are using login.jsp as a valid page? Is this group of users that are using the custom login page more important (for a lack of a better term) than customers hitting the login.jsp page? I have to question the level of effort to make this work as desired vs. the benefit. I have a fuzzy recollection of an 8.x feature to perform custom custom redirection but I can't find it in documentation. I don't remember the context other than something to do with URLs or redirecting to web pages so I am not sure if this newish feature is a possible solution. Beyond Remedy stuff if your users that need a special login page have some way they can be identified by their machine (like computer subnet, etc.) you probably do something fancy with Apache httpd (mod_rewrite) or scripting in IIS. Still wondering if the ROI is there though. Jason On Thu, Aug 28, 2014 at 10:06 AM, Champagne, Susan <schampa...@hsnsudbury.ca> wrote: ** Hi folks, I’m trying to find out where the workflow is coming from that causes the login.jsp page to display when using a customizedLogin.jsp page encounters ARERR 9388 (Authentication failed).We have a customized login page for a group of users, which displays correct; the problem occurs when the user mistypes his/her user name or password and encounters the Authentication failed error. As the error appears, the window and url change to display the url and page for the login.jsp.We’re using Mid Tier with Remedy 7.6.04.Can you assit, please?Susan Champagne**************************************************************** The information contained in this e-mail and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this e-mail is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this e-mail or its content in any way. _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"
