> "GET /?cosign-www.example.psu.edu&https://www.example.psu.edu/";
That looks like the URL that is seen by the weblogin server, it is never seen by the filter. After logging in, the user will be redirected back to the cosign-protected web server to a URL such as: https://www.example.psu.edu/cosign/valid?cosign-www.example.psu.edu=abc1123etc&https://www.example.psu.edu/webapp Of course, if after logging in, the user is redirected to <https://www.example.psu.edu//?cosign-www.example.psu.edu&https://www.example.psu.edu/ > then the filter will probably throw up some sort of error as this is not the expected format of the validation handler. Jarod On Aug 12, 2009, at 7:14 PM, Phil Pishioneri wrote: > On 8/10/09 5:05 PM, Jarod Malestein wrote: >> If the service name (that appears in the /cosign/valid query string) >> does not being with "cosign-", the IIS filter will generate this >> error. >> > > The name as it appears in the config is <Name>cosign- > www.example.psu.edu</Name>, and I see the matching name, in v3 form, > in the redirect URLs on the Cosign cgi side: ( name changed to > protect the innocent :-) > > "GET /?cosign-www.example.psu.edu&https://www.example.psu.edu/"; > > It's like the location handler isn't finding the value that the rest > of IISCosign found. > > -Phil > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Cosign-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
