[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: return parms in http_url_post_xml
Thanks for the reply Scott. I will review our setup and see what is
best. The setup leaving LIBHTTP as is sounds better.
Re: security I need to have a think.
Regards
Declan
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
Klement
Sent: 03 September 2008 19:24
To: HTTPAPI and FTPAPI Projects
Subject: Re: return parms in http_url_post_xml
> My question is around the library setup and HTTPAPI. Can I simply copy
> the /Copy routines, objects etc. that I require from LIBHTTP into my
> own (test/production)library and go from there.
Depends on how you build HTTPAPI. There were options about whether the
library list should be used or not. If you answered them so that the
library list is used for everything, then you can copy the stuff to your
own library and it should work properly. If not, you may have to change
some hard-coded references to LIBHTTP.
However...
I don't recommend making your own copy of the HTTPAPI code/programs.
This makes it significantly more difficult to upgrade HTTPAPI -- since
you'll have to repeat the process of copying it, etc.
Instead, I recommend keeping HTTPAPI and the code you downloaded with
HTTPAPI in the LIBHTTP library. Put your own code that calls it into
your own test/qa/prod libraries.
It's not any different from the operating system. You don't copy the
objects from OS/400 into your test/qa/prod libraries, do you? No, you
reference them from QSYS, and the same objects are referenced from all
of your environments. When you upgrade OS/400, you upgrade it for all
environments at once.
That makes it a lot easier to upgrade HTTPAPI (or OS/400) since you can
just delete the old library and create a new one, and you're done.
But... that's just my suggestion. You certainly *can* copy it into your
own libraries and test it in test/qa/prod environments, just as you
would your own code.
> Also do I need to concern myself about security with transaction
> sending? Sorry I am new to the web service world, any help would be
> appreciated.
Doesn't matter what you're doing... you always need to concern yourself
with security! (That's about the only safe way to answer that
question, heh.)
But, realistically... you need to look at the information you're sending
and how you're sending it and make a determination. I can't make that
determination for you. I don't know whether the data is encrypted in
the transport (i.e. SSL) or encrypted at the data level. I don't know
what data you're sending, or how sensitive it's considered. I don't
know your company's business or how big of a risk you're willing to
take.
However, you should understand this: If your URL starts with 'http:',
then HTTPAPI sends it unencrypted. Anyone who can gain access (lawfully
or unlawfully) to one of the routers or networks between your computer
and the one you're exchanging information with can therefore see
everything you're sending. Unless you've taken your own measures to
prevent that. 'http:' is also vulnerable to man-in-the-middle attacks,
since there's no reliable way to determine who it's talking to.
If your URL starts with 'https:' then HTTPAPI is using SSL, which has
safeguards. It uses digital certificates to guard against
man-in-the-middle attacks, and it uses encryption to protect the data
against visibility. Can these measures be broken? Probably, but it's
a lot harder than the non-SSL variant.
Are you willing to take the risks? I can't decide that, only you can.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
____________________________________________________________________
This email is intended for the designated recipient(s) only, and may be confidential, non-public, proprietary, protected by the attorney/client or other privilege. Unauthorized reading, distribution, copying or other use of this communication is prohibited and may be unlawful. Receipt by anyone other than the intended recipient(s) should not be deemed a waiver of any privilege or protection. If you are not the intended recipient or if you believe that you have received this email in error, please notify the sender immediately and delete all copies from your computer system without reading, saving, or using it in any manner. Although it has been checked for viruses and other malicious software (?malware?), we do not warrant, represent or guarantee in any way that this communication is free of malware or potentially damaging defects. All liability for any actual or alleged loss, damage, or injury arising out of or resulting in any way from the receipt, opening or use of this email is expressly disclaimed.
______________________________________________________________________
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------