[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Sending data - need explanation of how to begin - cookies
Sender: "ian" <ian@xxxxxxxxxxxxxxxxx>
Cookies handling.
In Scott's last reply he mentioned that cookies can be complicated.
They sure can be.
We have to read a cookie from the first connection in a session to a
particular Webserver, and then put the cookie back into each POST we do
afterwards. In this way the remote server knows that we are
sending/receiving data for the same 'session'.
Below is some psuedo code how we achieve this. Applogies for some very
inelegant code.
Firstly you need to know how the cookie is defined in the response from
the remote server.
In our situation, the cookie value is defined in the HTTP header
starting with 'Set-Cookie: JSESSIONID='
Here is the response from httpapi debug to our initial GET:
recvresp(): entered
HTTP/1.1 200 OK
Date: Thu, 22 Dec 2005 09:11:00 GMT
Server: Apache
Content-Length: 162
Set-Cookie:
JSESSIONID=Dqn5W6BVjq6brDv3jf3GK58rcdnsP7v2RgGNzcwvfHRBc2smyvW5!-5654147
48!wls02-ss201.test.bacs.co.uk!7001!7002; path=/
Connection: close
Content-Type: text/xml
In order to read this, we use the procedure read_hdr
2325.00 P read_hdr B
2326.00 D read_hdr PI
2327.00 D hdr 2048A const
2328.00
2329.00 c eval http_header_in = hdr
2330.00 c return
2331.00 P E
Before the procedure is used, we setup the link to the appropriate part
of httpapi with xproc:
0540.00 c callp
http_xproc(HTTP_POINT_PARSE_HEADER:
0541.00 c %paddr('READ_HDR'))
The procedure is called automatically when we have received the response
to our GET
We then scan for the 'JSESSIONID' string to get the cookie value:
1035.00 c* the http header should have been filled by proc read_hdr
1036.00 c* get JSESSIONID from header
1037.00 c eval JSession_start =
%scan('JSESSIONID':
1038.00 c http_header_in)
1039.00 c if JSession_start > 0
1040.00 c eval JSession_end =
%scan(CRLF1:http_header_in:
1041.00 c JSession_start)
1042.00 c eval CookieLen = JSession_end -
JSession_start
1043.00 c eval SessCookie =
%SUBST(http_header_in:
1044.00 c JSession_start:CookieLen)
Not quite finished yet. Unfortunately we need to convert some special
HTTP characters in the received value to be able to send it back. We
replace '+' chars with a blank, and we use this table to convert the
other special characters:
2395.00 **CTDATA TabHex
2396.00 %3D=
2397.00 %2F/
2398.00 %3B;
2399.00 %21!
The SessCookie now contains the cookie data in a format we can send it
back in the HTTP headers of our POST'S
We setup additional header data for our POST with this proc:
2333.00
*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2334.00 * Set additional http headers
2335.00
*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2336.00 P addl_hdr B
2337.00 D addl_hdr PI
2338.00 D addl_data 1024A varying
2339.00
2340.00 c if SessionCookie <> *blanks
2341.00 c eval addl_data = 'cookie: '+
2342.00 c %trimr(SessionCookie) +
x'0d25'
2343.00 c else
2344.00 c eval addl_data = ''
2345.00 c endif
2346.00
We use the xproc proc to setup this additional header info.
First setup the xproc link:
0542.00 c callp
http_xproc(HTTP_POINT_ADDL_HEADER:
0543.00 c
%paddr('ADDL_HDR'))
The 'cookie: JSESSIONID......' header is then automatically sent with
our next POST.
Hope this helps in some way.
Regards,
Ian Patterson
-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx] On
Behalf Of Scott Klement
Sent: 05 January 2006 18:00
To: ftpapi@xxxxxxxxxxxxx
Subject: Re: Sending data - need explanation of how to begin
Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>
> First, their site self certified certificate needs to be installed.
> The certificate expires in a few months.
You need to get their CA certificate from them... if they're using
self-signed certificates they should have this available for you to
download and install on your system.
You'll need to install it into the *SYSTEM certificate store in the
Digital Certificate Manager (which is a component of OS/400) and then
configure it so that applications "trust" it. (Otherwise they won't
connect to to the site.)
> Once that is done, then, you are allowed to click on a link to login.
> I looked at the page source, but this appears to all be javascript.
Bummer. You'll have to decipher what actually gets sent to the web page
in order to determine how use HTTPAPI with this. The JavaScript will
make
that MUCH harder to do.
The way I usually figure something like this out is to set up a "test
environment" where I can use the same JavaScript to send to my own
(unencrypted) server. I'll send some test data to the server, and use a
packet sniffer to watch what is sent. Then I can instruct HTTPAPI to
send
the same thing.
The other thing that will be complicated... Cookies. A lot of sites
like
this will set and use cookies in the browser. In HTTPAPI you have to
write your own code to process the cookies, it won't do it for you --
which makes this a lot more complicated.
> 1) Can HTTPAPI be used to connect to this server to upload data, based
> on the information I have presented so far?
Yes, but it may be complicated. It doesn't sound like this server is
intended for program-to-program communications. It sounds like it's
intended for a user to connect and key data in through a web browser.
You might ask the company you're doing business with if they have a "Web
Service" you can use instead of the manual user-driven process. That
would be easier.
However, it _is_ possible to automate the user driven process with
HTTPAPI, it'll just be a lot more difficult than a web service would be.
> 2) Is there an example or series of examples that I could use to get
> this done, and if so, what would they be?
The examples are source members called EXAMPLE1, EXAMPLE2, EXAMPLE3 . .
.
all the way up to . . . EXAMPLE17 and are included in the HTTPAPI source
files.
> 3) I have been following this list for a while, and I do not know how
> I
> am supposed to determine the method used. For example, I have seen
> mention of POST. But, how can I identify what is being requested and
> how do I send it? Since the server is javascript based, with
clickable
> links visible only after login, how (or can) HTTPAPI make the
> connection?
On the Web page where you do the upload, there'll be a <FORM> tag.
It'll
say something like <form action="post" method="/cgi-bin/mypgm.cgi"> (or
similar) this tells you that you have to use the POST method and that
the program to POST to is called
http://www.example.com/cgi-bin/mypgm.cgi
Since it has a file upload, there's a good chance that you'll have to
look
at MIME encodings as well. it might say <form
enc="multipart/form-data">
which tells you that you have to use HTTPAPI's http_mfd_encoder_xxx()
routines to encode your data before sending it.
Since there's a file upload, I'd say it's a 99% chance that this is
using
a POST -- I'd be shocked if they used GET for a file upload. (Though,
it
might work if the files are always very small)
> 4) Is a self signed certificate secure? I work in a hospital, thus
> HIPPA is a HUGE issue. Data MUST be secure.
Whether the certificate is self-signed has nothing to do with how
"secure"
it is. Signing a certificate has to do with "trust" not security. You
believe that the other company REALLY IS who they claim to be because
you
trust the certificate authority (CA) who created the certificate. If
that
CA only sells certificates to companies that have verified the identity
of
the certificate holder, then you know that they are who they claim to
be.
That's what a certificate is for.
With a self-signed certificate, you can no longer put your trust in a
company that specializes in signing certificates (like VeriSign or
Thawte)
but instead you have to trust the company who signed it. If you know
that
company and work with them all the time, this shouldn't be an issue. On
the other hand, if you're surfing the web and connecting to some
retailer
you've never heard of before, you want there to be a public signer so
that
you know that they're legitimate.
Whether the data is actually "secure" is probably more a factor of how
well it's encrypted during transit. And, the use of self-signed vs.
public certificates has no impact on that.
In any event, whether something is "secure" is a very subjective
question. What I consider to be secure and what you consider to be
secure
may be different things. What your boss considers to be secure may be
completely different than either of us.
If I put a lock on the door of my house, is my house reasonably secure?
Maybe I think so, but maybe you don't. What if I add an armed guard?
Is
it now secure? Someone could potentially evade the guard, and pick the
lock... What if my house is located underground with a minimum of 6
feet
of ground surrounding all of the walls, and only one door that's made of
3
inch thick steel with a really heavy duty unpickable lock, and an armed
guard outside that only has to secure this one door. Is it now secure?
Maybe... but the US Army wouldn't have much trouble breaking in.
At what point is something considered "secure"? It's entirely a matter
of
opinion, and is based on the level of risk that you're willing to take.
I might not be worried about an Army breaking into my house to steal my
computer equipment. But I am worried about a neighborhood kid. So
locks
on my doors might be sufficient. On the other hand, if I'm protecting
the
president of the united states... it's all a matter of the level of
risk you're willing to take, and what you consider to be secure...
A good introduction to how SSL works can be found here:
http://httpd.apache.org/docs-2.0/ssl/ssl_intro.html
That intro is part of docs about how to set up the Apache web server for
SSL communications -- but the info about how SSL works is the same for
HTTPAPI as anything else that uses SSL.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------