Not offended here. Realities of a small company and small IT team often get in the way of what's best. I am the only one here that knew the AVR.net application. I used past-tense deliberately, because among all the other skills I need to learn and use, my AVR.net is seldom used. It would take me a lot of time to reacquaint myself with that skill set to be able to make any web site modification. So keeping that task in-house does not lend itself to nimble and speedy service here. And sometimes mgmt signs contracts with vendors first and consults IT later (if at all).

I just need to know how I need to do my part as responsibly and professionally as I can.
-- MK
~~~~~~~~~~~~~
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Aaron
Bartell
Sent: Tuesday, February 03, 2015 9:53 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Security for web site accessing i via IWS

Opinion and unbridled honesty warning....

It is amazing to me that in 2015 businesses are still taking this approach
to their next generation of technological viability, which inherently is
business viability. This approach of having such disparate teams will
significantly slow anything produced with this technology stack and the
business will immediately be at a disadvantage to the competition. The
next real competitive advantage is how fast a business can deliver
features and not just delivering "keeping up with the Jones'" technology.
Everybody has technology at this point, but not everybody can move fast
because that takes very careful selection of a technology stack.

The only thing gained is a pretty interface, and that will satisfy
customers for awhile, but only for so long. Soon customers will start
asking why their requested features are taking so long to procure. They
will then point at your competition and comment on how they are
progressing much faster.

One final comment. Of all parts of the stack, the UI layer
(HTML/CSS/Javascript) is the easiest to have on the IBM i because none of
it actually runs on IBM i and instead it is only delivered by the IBM i.

I hope I didn't offend you personally, I just wanted to provide feedback
based on my experiences with many web projects over the years.​

Aaron Bartell

KrengelTech
Litmis Team - litmis.com​

On Tue, Feb 3, 2015 at 8:28 AM, Koester, Michael <mkoester@xxxxxxxxxxxxx>
wrote:

Hi Aaron.
This piqued my curiosity. What language is the web design company
developing the front-end site in?

Sorry to say, I don't know... I'm fairly certain they have no
familiarity with IBM i. Most of the contact with that firm has been
by mgmt and marketing. There's supposed to be a meeting where I get
to meet with either a developer or project mgr (probably a joint
meeting with marketing and mgmt), but that hasn't yet happened.

I established awhile back that I would develop web services that would
return an XML document with all the data elements needed for a
customer to navigate the site. I will provide them with a design
document describing what they need to do to request data, and the
specifics of the data elements and types I return. They would take it
from there to design a site that is functionally equivalent to the one
currently in use.
Additional features and function are planned, but have not yet been
designed with any detail.

-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Aaron
Bartell
Sent: Tuesday, February 03, 2015 8:31 AM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Security for web site accessing i via IWS

​>Management now wants to have an outside firm with more web design
expertise to manage and maintain the presentation layer, so my
challenge is how to accommodate that

This piqued my curiosity. What language is the web design company
developing the front-end site in?

Aaron Bartell

On Tue, Feb 3, 2015 at 7:24 AM, Koester, Michael
<mkoester@xxxxxxxxxxxxx

wrote:

Thanks Nathan.
The current situation has the scenario you described -- the web
site we developed in 2007 using ASNA's AVR.net with their DataGate
interface to the database has handled all that quite nicely. All
access was through a https URL.

Management now wants to have an outside firm with more web design
expertise to manage and maintain the presentation layer, so my
challenge is how to accommodate that. Where we had a very tight
integration with the database, we will now be passing the required
data elements on request to the outside firm to use to manage the
site navigation. When an action requires posting a settings
change (payment account details, auto-pay, paperless billing) or a
payment commitment, I'll handle those with web service operations
that update our database or post the payment and return a
confirmation number.

The session (for my purposes) begins with the request for the data
elements pertaining to an account. Subsequent calls to the "post"
operations include the account number and session number, and are
matched by my programs to the most recent session established for
that
account.
I'm anticipating those requests to follow generally within a few
seconds to a few minutes of the data request, but will probably
consider the session to be expired in an hour (I keep timestamps
when the session IDs are established). I plan to discuss the
particulars of
reasonable "timed-out"
expectations with the website people.

I just need to understand what needs to be done to protect the
customer data in transit, and to ensure that the web server is the
only
way in.

Thanks again,
-- Michael
~~~~~~~~~~~
-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of
Nathan Andelin
Sent: Monday, February 02, 2015 6:19 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] Security for web site accessing i via IWS

Just a couple quick points. It sounds like your interface would
be more streamlined if both your web site and your web service
were running on
the
same server, and that security would be easier to establish and
maintain thereby. You might also consider how to expire your
sessions, and what to do after that.





On Mon, Feb 2, 2015 at 10:20 AM, Koester, Michael <
mkoester@xxxxxxxxxxxxx>
wrote:

Seeking advice on security to and from a web site and the IBM
i
database...
I'm developing the back-end web services to support a redesign
by a business partner of a website used for Bill Presentation
and
Payment.
Customers' account details, including payment account info,
are to be inputs to the web service, and obviously need to be
secured as they traverse the communications links. I need to
know that what I'm doing is sufficient -- at least that I've
made what is a reasonable effort to protect customer data.

My web services use the IBM Integrated Web Services (IWS),
calling i
7.1 RPG programs to retrieve and update our i database, and
staging committed payment data for ACH transactions. PTF's
for HTTP and IWS
are
current.

Here are the elements of my design:
1) The web site will be accessible to the user via SSL. This
will be the responsibility of the web site developer.
2) All traffic to and from the IWS operations will use SSL,
with a self-signed certificate provided by our SysAdmin to the
web site
developer.
3) The web site developer is responsible for user
authentication prior to calling the web service operations.
4) When a user is authenticated, the web site script makes a
call using SSL to a web service operation to retrieve the
details of the customer account.
5) My RPG program that retrieves the account details generates
a 10-digit "SessionID" which is returned with the account data
to the web
site.
6) Calls to subsequent operations (PostSettingschange and
PostPayment) by the web site must include that SessionID,
which I use to log the session activity to a log file, and to
track what data has been sent to the web site.

I'm sure that there are no absolute guarantees of security,
and that there may be a myriad of expensive add-ons to make
the process incrementally "more secure", but have I missed
something that would make my plan irresponsibly inadequate?
Are there things about SSL that I need to check to ensure that
SSL flaws exposed last summer have been remedied? What are
other shops doing
to handle these concerns?

Many thanks.
Michael Koester
Programmer/Analyst
DataEast


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/web400.

--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400)
mailing list To post a message email: WEB400@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.


--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list To post a message email: WEB400@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.