I don't think it's nonsensical to expect a sane user feedback form on a
web site for an enterprise by a large corporation like Westpac,
particularly when a major redesign/upgrade of the web site was completed
only reasonably recently. I've worked on enterprise systems myself and
to be honest I'm not really sure what you are suggesting. It seems like
you are saying that data input in one part of an enterprise system
should be able to be used in all other parts of an enterprise system
without any sort of filtering or consideration of the issues and should
automatically be considered too hard. In my experience that's how you
*create* horrible legacy systems where everything is always done the
same way out of lack of understanding of the system and fear something
will break.
 
As others have pointed out, this is a user feedback form - if it is
going to be used by other parts of the enterprise system then isn't that
what specifications and integration testing are for? At what point in
your opinion does the security issue become nonsensical? When you aren't
allowed to enter any punctuation or numbers or lower case characters or
is that still a reasonable thing to do given there are other systems in
the enterprise that are 10-20 years old?
 
Cheers,
Ben


________________________________

        From: ozdotnet-boun...@ozdotnet.com
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Ken Schaefer
        Sent: Wednesday, 27 October 2010 1:00 PM
        To: ozDotNet
        Subject: RE: Rant
        
        

        I'm sure systems can cope - but there are a number of
challenges:

        a)      System boundaries: what one system finds acceptable may
not be acceptable to another (apostrophes I'm sure we're all well aware
of)

        b)      Unicode is probably something that older systems can't
cope with

        c)       It wasn't that long ago that SQL injection and XSS
become hot topics - what about older GUIs written many years ago that
are used by branch staff or call centre staff. Would they be able to
cope?

         

        Whilst it may be poor coding, the effort required to fix the
problem is immense. So saying "in this day and age I expect x" is a bit
nonsensical. What's so special about writing code today that makes
effort required to remediate enterprise systems just go away? Or that
makes today's code able to handle the challenges of the next 10-20
years? Nothing as far as I'm aware.

         

        Cheers

        Ken

         

        From: ozdotnet-boun...@ozdotnet.com
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Paul Gaske
        Sent: Wednesday, 27 October 2010 12:29 PM
        To: ozDotNet
        Subject: Re: Rant

         

        Oh; I dunno.  I'm thinking you're right to jump up and down.
Especially if you've got an apostrophe in your name or a hyphenated last
name.  Congratulations, you're now a security risk!

         

        Seems like a bit of a fail to me.  I'm sure banking systems, no
matter how long ago written, would be able to handle hyphens or
apostrophes.  This really does sound like poor coding to me.

         

        Cheers,

        Paul.

        On Wed, Oct 27, 2010 at 2:25 PM, Stephen Price
<step...@littlevoices.com> wrote:

        It's very easy to jump up and down about this sort of stuff when
it
        doesn't work. Your email has made me pause and think about it,
and
        let's be honest, this coding stuff we do is complicated. So many
        variable (pardon the pun), so much can go wrong. It doesn't
always
        work as intended. If it was easy then everyone would be doing
it.
        
        I know I strive to better my coding skills continually, and even
after
        years of coding I know there will still be bugs in my code. I
don't
        trust my own code (possibly a good trait, apparently) and use
unit
        tests etc to help improve the code quality.
        
        It wasn't so long ago that you had to physically walk into a
bank to
        do your banking. It's become mainstream so fast. I can see how
you
        would jump up and down about a user having to enter their data
        correctly, but I guess there has to be some validation. Is there
a
        feedback section that would allow you to let them know so they
can add
        it to their "to be fixed" backlog? If you don't let them know
(and no
        one else does) then you get what you put up with. I often send
emails
        or feedback to companies when I find issues with things. It
doesn't
        always make it to the right person but at least I tried.
        
        cheers,
        Stephen

        
        On Wed, Oct 27, 2010 at 12:10 PM, Ken Schaefer
<k...@adopenstatic.com> wrote:
        > Hi,
        >
        >
        >
        > Just because a UI is now in neat HTML doesn't mean that every
backend
        > system, and every other system used to access this data, can
cope.
        >
        >
        >
        > I worked on Westpac's IB upgrade project (the monitoring part)
and it's a
        > huge amount of work just to upgrade one small part of it.
        >
        >
        >
        > Cheers
        >
        > Ken
        >
        >
        >
        > From: ozdotnet-boun...@ozdotnet.com
[mailto:ozdotnet-boun...@ozdotnet.com]
        > On Behalf Of ben.robb...@jlta.com.au
        > Sent: Wednesday, 27 October 2010 9:21 AM
        > To: ozdotnet@ozdotnet.com
        > Subject: OT: Rant
        >
        >
        >
        > <Rant>
        > I just ran into the following text on the Westpac Altitude
Rewards web site.
        > I am amazed that in this day and age that the developers
and/or designers
        > for a banking-related web site have just *given up* and are
forcing their
        > customers to clean their data.
        >
        > Note that if your message does include any of the characters
you get an
        > 'input error' feedback but you still have to find the
offending characters
        > and clean it yourself. Unbelievable!
        >
        > </Rant>
        
        

         


This email is intended for the named recipient only.  The information it 
contains may be confidential or commercially sensitive.  If you are not the 
intended recipient you must not reproduce or distribute any part of this email, 
disclose its contents to any other party, or take any action in reliance on it. 
 If you have received this email in error, please contact the sender 
immediately and delete the message from your computer.

Reply via email to