Re: Sending data - need explanation of how to begin

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

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
-----------------------------------------------------------------------