LOADFORM in GCF

The form I am working with has no name (reminds me of a horse ... nevermind, that's a song :) ) .... but the doc says "if the form does not have a name, it will still work within the GCF if there is only one form in the HTML."
Which this is the case.

So, suppose the actual form (when in view source) is something like this:

<table border=0 summary="">
<form method="POST" action="/blah/auth" AutoComplete="off">
<INPUT TYPE="hidden" NAME="v" value="v1.4">
<INPUT TYPE="hidden" NAME="sometoken" value="v1.2~B34C0BB1~6C05EF0312234D2CE">
<INPUT TYPE="text" SIZE="30" MAXLENGTH="50" ID="c2" NAME="UserName" value="">
<INPUT TYPE="password" SIZE="30" MAXLENGTH="50" ID="c3" NAME="password">
</form>

Since sometoken (and v) are already filled in when I navigate to the login page and view source, I thought I'd only have to SET the UserName and password

However the logs look something like this (abbreviated version): (Notice there is no mention of token or v).

... LOADFORM
....... Executing SET
..... Executing SET: LoginForm.UserName = hopkinca
....... Executing SET
Executing SET: LoginForm.password = ***somepassword***
Executing SESSION

I don't even know if the other variables are being loaded, I have doubts because since later in the logs my login error on the external system is 500 Internal Server Error.
If I try to login using my own HTML form (and a recent "some token" which are created by the ext sys on the fly) I CAN log in. When I leave out the "sometoken" I get the same 500 Internal Server Error.

I have all debugging turned on, but still cannot figure out exactly what's going on by the logs, so therefore I am guessing.

FINALLY, my question!!!!!!!!!!!!!!! What am I doing wrong?

If I need to SET the "sometoken" ...... then I'll have to use GRAB, which

* I've used successfully before but am having problems this time using it
* If I use GRAB I might as well use the pickup response method. The reason I switched from response to html is to avoid the GRAB!

(I have

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More ...

I found this before the "LOADFORM" debug statements in the cpipconnector.log. See bold.
Does anyone know what it means? does it mean it can't navigate to the page where the login source is ?

[2009-04-30 10:52:59,947] [DEBUG] http-8008-Processor22:/orport/Authenticate org.apache.commons.httpclient.HttpMethodBase.getContentCharSet:2183 enter getContentCharSet( Header contentheader )
[2009-04-30 10:52:59,948] [DEBUG] http-8008-Processor22:/orport/Authenticate org.apache.commons.httpclient.HeaderElement.parseElements:237 enter HeaderElement.parseElements(String)
[2009-04-30 10:52:59,948] [DEBUG] http-8008-Processor22:/orport/Authenticate org.apache.commons.httpclient.HeaderElement.parseElements:193 enter HeaderElement.parseElements(char[])
[2009-04-30 10:52:59,948] [DEBUG] http-8008-Processor22:/orport/Authenticate org.apache.commons.httpclient.HeaderElement.getParameterByName:278 enter HeaderElement.getParameterByName(String)
[2009-04-30 10:52:59,949] [DEBUG] http-8008-Processor22:/orport/Authenticate org.apache.commons.httpclient.HttpMethodBase.getContentCharSet:2201 Default charset used: ISO-8859-1
[2009-04-30 10:52:59,949] [DEBUG] http-8008-Processor22:/orport/Authenticate com.campuspipeline.sso.authenticator.HttpSteps.setLocation:1467 Setting Location for method
[2009-04-30 10:52:59,950] [DEBUG] http-8008-Processor22:/orport/Authenticate com.campuspipeline.sso.authenticator.HttpSteps.setLocation:1475 Cound not get Response Header=>location, setting it null
[2009-04-30 10:52:59,950] [DEBUG] http-8008-Processor22:/orport/Authenticate com.campuspipeline.sso.authenticator.HttpSteps.opLoadForm:1129 Executing LOADFORM
[2009-04-30 10:52:59,950] [DEBUG] http-8008-Processor22:/orport/Authenticate com.campuspipeline.sso.authenticator.HttpSteps.opSet:1165 Executing SET
[2009-04-30 10:52:59,951] [DEBUG] http-8008-Processor22:/orport/Authenticate com.campuspipeline.sso.authenticator.HttpSteps.opSet:1174 Executing SET: LoginForm.UserName = mynamehere
[2009-04-30 10:52:59,951] [DEBUG] http-8008-Processor22:/orport/Authenticate com.campuspipeline.sso.authenticator.HttpSteps.opSet:1165 Executing SET
[2009-04-30 10:52:59,951] [DEBUG] http-8008-Processor22:/orport/Authenticate com.campuspipeline.sso.authenticator.HttpSteps.opSet:1174 Executing SET: LoginForm.password = itisasecret
[2009-04-30 10:52:59,952] [DEBUG] http-8008-Processor22:/orport/Authenticate com.campuspipeline.sso.authenticator.HttpSteps.opSession:1299 Executing SESSION

seen this before

I can vaguely remember seeing this before. Fortunately it is vague.

First off, do you call a <GET> at the top of the <AUTHENTICATE>

this needs to be done before any <LOADFORM>

Secondly, what happens if you set up a webpage containing a FORM with a name - posting to the
system which you want to authenticate against? (even better if you can host the new webpage
on the system proper)

You may be able to use a name without complaints.

Derek
University of Leeds

Thanks for your

Thanks for your response!

Yes, I can submit from a "homegrown" form as long as I get a current "sometoken" ....
this is also one of my tests I always use (use my own form) to get a feel for what absolutely needs to go on the form and how complicated the login is. :)

Also, yup, :) I do a GET for the URL where the form resides. This URL I am "GET"TING, though, redirects.
like this for example: http://someextapp.shu.edu:7780/pls/portal/portal.home

http://someapp:7777/sso/jsp/login.jsp?sometoken=v1.2~B34C0BB1~66C47C52E

And I'm wondering if the redirection has anything to do with my problem. :)

I've tried "GRAB" and "GRABFROMHEADER" for this token but can't get it!!! But with this LOADFORM I don't think I'd need it, as soon as i land at the redirected url (above example) I can view source and see the "sometoken"

Some of my XML:
<CLIENT>
<SESSION a:server="${properties.externalSystemURL}">
<GET a:url="/" a:query="" a:redirects="yes" />
<GET a:url="http://someapp.shu.edu:7780/pls/portal/portal.home" a:query="" a:redirects="yes" />
<LOADFORM a:symbol="LoginForm" />
<SET a:symbol="LoginForm.UserName" a:value="${_USERNAME}" />
<SET a:symbol="LoginForm.password" a:value="${_PASSWORD}" />
</SESSION>

<SESSION>
<POST a:url="http://b-app1-rprt.shu.edu:7777/sso/auth" a:query="" a:redirects="yes">
<PARAM a:list="LoginForm" />
</POST>
<RESULT a:value="TRUE" />
</SESSION>
</CLIENT>

This one is much easier to solve

Assuming that the behaviour you are trying to reproduce is:

(Ordinary manual login)
a.1) Login page puts cookie token into the browser
a.2) Client browser posts FORM data

(Pickup response GCF)
b.1) Use an intermediate page to get the cookie token into the browser
i.e. http://myuni.leeds.ac.uk/site/uol/sso/cookiegetter/mysys.html

This html page contains an iframe src="actual login page that user visits in a.1)" and a
javascript < body onload="location=http://myuni.leeds.ac.uk/ip?sys=mysys" to start
off the GCF
b.2) GCF delivers an autoposting page to browser (from the AUTH steps and the pickup.response property)

(Pickup HTML)
c.1) AUTH step calls GET "actual login page that user visits in a.1)"
c.2) AUTH step calls LOADFORM, POST etc
c.3) AUTH step makes sure that the handover is ready
c.4) PICKUP step calls mysys pickup.html

I am fairly confident about the first 2 (a and b), but try not to touch c) very often.

Derek
University of Leeds, UK

Might not be possible?

Thanks, Derek.
I tried both the pickup html ("cookie getter") and pickup response method.
Instead of iframes, we use shortcuts to kick off the GCF. Has always worked for us before.

I put in a ticket with Sungard, finally, about this connector.

Their response (edited - partial).

From what I can see, the .. app is not sending a response. I have a good example from a Cognos report connector that did not return response headers, but did send a response.
Since the sitetoken variable is null, that is probably why the post fails. Have you tried using a tool such as wireshark? That could help you find what packets are sent back and forth.

I don't know much about portlets, but from what I understand, if the site/external system sends you tokens, your best bet is to develop a portlet rather than using GCF.

traffic snooping

Seeing the interaction between a browser, Luminis, GCF, and ES is quite hard.

I tend to put a connection proxy between GCF and the ES (so run a stand alone java app, which listens on a socket : say 8009, logs anything received and passes this on to ES, logs the whole response and
passes this back to GCF)

This technique starts to break down when https is used (and this should be used for all GCF!) but the SetCookies and http header traffic should all be in plain still (?)

Are you sure that the GCF webserver is handling the SSL handshake with the ES properly (i.e. that the right cert is in the GCF webserver certstore)

Derek

Proxy ....

Are you sure that the GCF webserver is handling the SSL handshake with the ES properly (i.e. that the right cert is in the GCF webserver certstore)

Thanks, Derek.   Actually, no I'm not positive that the GCF webserver is handling the SSL handshake with the ES properly.  However, we have other connectors that successfully use GCF with SSL ..... I would think this imply something is wrong on the ES side?  Not sure.

Unfortunately I'm not quite sure how to put a connection proxy between the GCF and the ES.  I know you tried to explain in your post, but I've never done this.

Thanks for your help ....

 

I wasn't thinking properly

I wasn't thinking properly when I answered your question about the SSL handshake.
This ES does not use SSL!

However, I did get the connector working!

I will post my "secret" to SSO to Oracle Portal shortly.

 

 

Oracle Portal Applications Server Portal Builder GCF

I have finally gotten the Oracle Portal AS Portal Builder connector working!!!!!!!!!! 

A few glitches with the autosync process, but am trying to iron them out and will probably post about them.

However, seems the ES was not sending back the RESPONSE  or RESPONSE HEADERS in a way that GCF could GRAB from. However, I ended up googling the parameter value in the form that I needed to grab.

I found it on an oracle website in korea!

If you want to create a GCF to Oracle POrtal, and need to do a "GRAB" on the site2pstoretoken,  read this:  http://kr.forums.oracle.com/forums/thread.jspa?threadID=410598

Worked like a charm. Was able to grab from that URL (portal/pls/portal/portal.wwptl_login.show_site2pstoretoken)

Syndicate content