whoops did not see that axton. On 1/31/07, Axton <[EMAIL PROTECTED]> wrote:
** Add the bits together to implement multiple parameters. e.g., a value of 31 will disable all callbacks. Axton Grams On 1/31/07, Ben Chernys < [EMAIL PROTECTED]> wrote: > > ** First, I would code the AREA plug-in to handle all calls properly. > You do not need to authenticate on the subsequent calls unless a timeout is > reached. You will need to provide address info and an OK return code. > > Then, yes, 16 seems like it should work though the comments are > confusing. Perhaps 7 is more correct. > > Note that you will have to restart the plug-in server to reload this > value. > > Try it and see.... > Ben > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Mikhail Serate > *Sent:* January 30, 2007 10:33 PM > *To:* [email protected] > *Subject:* Re: SSO Problem: AREA being called more than once > > > ** Hello Ben, > I looked at the Configuration Guide's list of the parameters related to > area and notification and this is what i found: > > Option: > External-Authentication-Return-Data-Capabilities > > Description: > A bit mask that allows you to specify the return data capabilities for > the current AREA plugin. This setting does not control the AREA plugin, it > merely desecribes the behavior of the plugin, allowing for server > optimization. Acceptable values are as follows: > - Bit 1 (Value = 1) - no email address will be provided > - Bit 2 (Value = 2) - no notify mechanism will be provided > - Bit 3 (Value = 4) - no group identifiers will be provided > - Bit 4 (Value = 8) - no license information will be provided. > - Bit 5 (Value = 16) - no notification user validation should occur. > The default is 0, meaning the server wil attempt to retrieve this > information from AREA. A value of 7 will allow the server to potentially > reduce the number of AREA related calls during notification processing. > A value of 16 will allow the server to avoid using AREA for notification > user validation and information retrieval. Use this setting for sites using > a form of AREA that applies user names as email addresses and where there is > no benefit to accessing an authentication database. > > So if I put the External-Authentication-Return-Data-Capabilities in the > ar.cfg and set it to 16, will ARS stop calling AREA twice? > > *Mikhail Serate* > Remedy Development Team > Information Technologies > University of Calgary > (403) 210-9308 > [EMAIL PROTECTED] > > > ---------------------------------------------------------------------------------- > *Some people see things as they are and say... "Why?" > I dream of things that never were and say... "Why not?"* > > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Shanmugadas, Suresh > *Sent:* Monday, January 29, 2007 2:28 PM > *To:* [email protected] > *Subject:* Re: SSO Problem: AREA being called more than once > > > ** *Hi Mikhail/Fellow Listers* > ** > I am facing the exact same problem like yours today. but I am > implementing AREA SSSO for the firsttime in 7.0.1. I am passing 2 secret > passwords from Midtier. So when the Callback function in AREA is called > , it validates these values and it is successful. but it gets called again > for some reason and this time it is getting my windows login credentials in > the parameters sent to AREA and it is failing. > > > > Our Env: > > ARS 7.0.1 > Midtier 7.0.1 > Win 2003 server > IIS/TOMCAT > IE > > > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Username: > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> > [EMAIL PROTECTED] > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Password: > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> FIRSTPASS > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Network Address: > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> 10.XXX.XX.XXX > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Auth String: > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> SECONDPASS > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> From AREA > PASS_STRING: > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> FIRSTPASS > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> From AREA > AUTH_STRING_DEFAULT: > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> SECONDPASS > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> User logging in > from a matching Authentication String and Mid-Tier IP: > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> 10.XXX.XX.XXX > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> User passed AREA > SSO authentication. Login Success > <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > > <Client-RPC: 390695> -VL OK > <PLGN> <TID: 000472> <RPC ID: 0000000003> <Queue: AREA > > <Client-RPC: 390695> +NS AREANeedToSyncCallback > <PLGN> <TID: 000472> <RPC ID: 0000000003> <Queue: AREA > > <Client-RPC: 390695> -NS OK -- 0 > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> +VL AREAVerifyLoginCallback -- user > suresh.shanmugadas > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Username: > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> suresh.shanmugadas > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Password: > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO>xxxxxxxxxx > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Network Address: > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> 10.XXX.XX.XXX > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Auth String: > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> @schwab.com > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> From AREA > PASS_STRING: > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> FIRSTPASS > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> From AREA > AUTH_STRING_DEFAULT: > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> SECONDPASS > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> User did not > provide a valid Password String. > <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> User did not pass > AREA SSO authentication. Login Failed > > > Any suggestions/advice please. > > > > > > Thank you > SK > > ------------------------------ > *From:* Action Request System discussion list(ARSList) [mailto: > [EMAIL PROTECTED] *On Behalf Of *Mikhail Serate > *Sent:* Monday, January 29, 2007 8:36 AM > *To:* [email protected] > *Subject:* SSO Problem: AREA being called more than once > > > ** > > Hi List, > Has anyone ever had any problems with their AREA being called more than > once? In the password field, a one-time-use token is being passed in. AREA > then calls SSO with that token, then SSO verifies the validity of the token. > However since the AREA code is being called more than once, the same token > that was being validated the first time it went through, is being validated > again, and so SSO of course will say no. > > The AREA code we are using now is exactly the same as our old AREA code > in ARS 6.3, which worked (we upgraded to ARS 7.0). Does anyone have any > thoughts on this? Please let me know. Thanks! > > *Mikhail Serate* > Remedy Development Team > Information Technologies > University of Calgary > (403) 210-9308 > [EMAIL PROTECTED] > > > ---------------------------------------------------------------------------------- > *Some people see things as they are and say... "Why?" > I dream of things that never were and say... "Why not?"* > > __20060125_______________________This posting was submitted with HTML in > it___ __20060125_______________________This posting was submitted with HTML > in it___ __20060125_______________________This posting was submitted with > HTML in it___ > __20060125_______________________This posting was submitted with HTML in > it___ > __20060125_______________________This posting was submitted with HTML in it___
-- Patrick Zandi _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
