Had just about enough nuff nuff

  • On 15 June 2012 14:23, <supportperson@vendor.example.com.au> wrote:

    > The additional login "xyzredacted" is now working, password is

    > "password" and just needs to be reset after login.

    Did you also try associating a second additional user with the

    "redacte" super user? If so, did that one work without needing IT


    > I'm still following up on the issue related to the other ghost
    > login, will update more as information comes to me.

    Thanks. It would be nice to be able to use "redacted" and not need to
    explain the missing "d" to everybody else.

    Were you also able to verify that using a 16+ character password while
    attempting to register a completely new account causes registration to


    On 15 June 2012 15:23, <supportperson@vendor.example.com.au> wrote:

    > IT has confirmed that whilst the School accounts were deleted
    > so we could start from scratch this didn't remove the login names
    > themselves from the system as I suspected and this was creating
    > conflict. IT have now removed these so you may now attempt to
    > change your login name and see how this goes.

    Having confirmed that attempting to log in as "redacted" *does* now
    result in "The login ID does not exist" rather than "Your account is
    still under pending" I am inclined to agree with you and expect no
    further difficulty.

    > IT have also advised that they are unaware of any character
    > limitations for the provided passwords so this isn't a concern.

    This is extremely annoying. How many times does a problem need to be
    reported to these people before they actually bother trying to confirm
    it for themselves?

    > They believe the issue originated when the first registration did
    > not provide a country, to avoid this in future the site will be updated to
    > make this a required field.

    They are wrong. There is no way to fill in a registration without a
    country, as it comes from a drop-down menu and Australia is the
    default. The problem occurs, as I have said over and over again, when
    you try to do a registration using a super user password that's 16
    characters or more.

    Please refer to the attached PDF files: signup-page.pdf was printed
    right before I clicked Submit, and result-of-signup.pdf is the
    resulting server error. You can't see the password in signup-page.pdf,
    but it was abcdefghijklmnop (16 characters).

    > Hope all is well now.

    I will be happy if you can assure me that IT has removed its
    collective head from its collective rectum and is now actually
    *fixing* your broken web app.

    Honestly, I don't want to be a pain about this. But I have to say that
    having gone the extra mile to *actually track down* the cause of your
    problem, I really don't appreciate being fobbed off and treated like
    an idiot by an IT department I can't even correspond with directly.


    On 15 June 2012 15:23, <supportperson@vendor.example.com.au> wrote:

    > Hope all is well now.

    Not so much. I successfully created a second additional user,
    smredacted (not a name I have used before) for Staff Member, but
    got the customary server error when attempting to log on with that ID.


    On 15 June 2012 16:35, <supportperson@vendor.example.com.au> wrote:

    > As before I can already see this creating similar issues and
    > I can already see a duplicate bogus request.

    If you are seeing duplicates of that request then the system is even
    more broken than I thought, because I only clicked Submit *once*.

    > Please hold off from trying to register the same School again
    > it only appears to be corrupting the system which we've only
    > just fixed.

    I have no interest at all in registering "the same School" (by which I
    assume you mean "Absolutely Bogus School") again. The only reason I
    did so (once!) in the first place is to demonstrate the existence of
    the long-password problem you assured me didn't exist.

    > This is just creating more issues before they can be fixed.

    No, this is *demonstrating* the *existing* issue that IT *refused* to
    fix. Please bring it to their attention. If they continue to claim
    that there is no issue with password length, have one of them attempt
    to register a test account using a 16+ character password *while you

    > Please advise exactly what the issue was with changing the login
    > redacte to redacted?

    I *did not* change the login "redacte" to "redacted", since doing so
    would have made it impossible for Competent Reseller, to whom I had
    already sent the "redacte" credentials, to log on.

    Since there is no longer a "redacted" account in your database, I do
    not expect to see any issue when I do so. But I will not attempt this
    until after Competent has finished using "redacte" to enter our
    recent purchases.

    What I did do was log in as "redacte" and use the account
    administration page to create a *second* additional user,
    "smredacted", for eventual use by Staff Member. This account
    was apparently created successfully. There was certainly no indication
    of any error after creation.

    However, when I logged off "redacte" and attempted to log on as
    "smredacted" I got exactly the same server error as I originally
    reported when logging on as "xyzredacted" before you fixed that one
    by hand. So I expect you'll find that "smredacted" also has the same

    If you could fix that one as well, I will happily agree not to
    interact with the Privilege Program web app *in any way* until after
    you can honestly tell me that the problems I have reported have been
    (a) reproduced on your end (b) properly tracked down and (c) fixed.

    And just to be perfectly clear, those problems are:

    1. Specifying a super user password of 16 characters or more when
    attempting to register a school always causes registration failure
    with a HTTP 500 server error.

    2. Usernames are not reserved on registration submission, only on
    registration approval. This makes it possible to create multiple super
    user accounts with the same username, only one of which will end up
    able to log on. If one of these is subsequently renamed, both will
    become able to log on.

    3. Additional users created via the super user's account
    administration page cannot log on; attempting to do so causes a
    HTTP 500 server error.


  • Dear supportperson,

    Thank you for bringing the issue${plural-s} to our attention. We have been assured ${itthey} no longer exist${singular-s} and have closed your ticket${plural-s}.

    We hope our service has been to your satisfaction.



  • A mindless mailbot would be less annoying than this support person, who in phone conversations has tried to tell me

    - maybe it's the apostrophe in the name of the school (no, it was trying to use a long password - 15 characters works, 16 doesn't)

    - maybe it's the dot you put in that username (no, the username with the dot worked fine after you fixed the "missing entity" by hand)

    - yes, everything related to you has been deleted (no, it still shows up as "under pending")

    - what I need you to do is stop trying to log in and just redo your registration (don't want to do that until you've fixed "under pending")

    - your multiple usernames are corrupting our database (fnnnnnnggggggggghhhghghhh)

  • I can't look into the code, but your complaints sound pretty valid and consistent. It's almost impossible that they're not the result of some lousy coding.

    However ... if that's the level of professionalism in this product, then it's scary to imagine what mess lies beyond the login screen. Run away if you can! Scram! Leave the dead behind!

  • The web app in question belongs to the local arm's cheesy loyalty scheme: buy X units off them, register them in this thing and you become eligible for free jelly beans or an extra netbook or some damn thing. The wider organization is a major hardware manufacturer. I have trouble believing they would ever have become major if this level of incompetence extends org-wide.

    I really don't want to dump them, mainly because I've been dealing pretty much exclusively with one of their resellers for years and years, and that reseller is really, really good.

    The hardware has always been pretty good value for name brand stuff, and warranty support has always been quick, competent and hassle-free, which is why this steaming turd of a web app strikes me as such a WTF. I'm pretty sure it's Marketing's baby.

    If I get no useful results from that last email I might try putting some sideways pressure on via the reseller, who handles a hell of a lot of their kit.

  • @flabdablet said:


    TOWTF [*]


  • @flabdablet said:

    The wider organization is a major hardware manufacturer.

    There's your problem. Letting hardware companies at software almost always leads to something utterly terrible.

    Brilliant ideas for saving money, like the guy who's spent the last few months designing the southbridge chip on your company's new motherboard should be able to help with the web app, because "It's all computer stuff".

    For examples of this problem, just look at nearly any router's config setup, or any networked appliance type thingy where the hardware company made a web interface.

  • As an ex-embedded-systems programmer, I'm all too familiar with the results of letting an EE get anywhere near a compiler.

    Has to be said, though, that the hardware I designed was none too great either 🙂

  • Round 2! Apparently just being cranky at them has pushed things along a little.

    On 18 June 2012 13:14, <supportperson@vendor.example.com.au> wrote:

    > Apologies for the delay in responding this feedback has been sent
    > to IT to look into further and this urgent issue is being dealt
    > with to resolve it for you as soon as possible. Pleasee allow us
    > 24 hours to complete testing and respond again.
    > Addtionally,  in regards to the password creation issue, the
    > only restriction we have is what is mentioned in the registration
    > form, 6 characters or more.  Its been confirmed that it is true the
    > maximum length for the text box is 16 characters.

    So there *is* another restriction, but the site just doesn't tell you
    what it is. And in fact 16 characters is enough to cause an internal
    server error. 15 characters is the maximum length that works.

    > Almost any other website login creation (like gmail) there is a
    > maximum limit of characters you can enter.

    Almost any other website doesn't suffer server errors and database
    corruption when you exceed that limit. And most websites that impose a
    maximum length restriction *tell you what it is* (Gmail being a
    notable exception).

    > Each application will have a maximum size for the password
    > text box which they consider reasonable. Most of our (VENDOR
    > Australia) websites it is 16 characters, since its not generally
    > anticpated anyone to enter a password that long.

    With mail account hacking becoming more common, you should expect to
    see an increase in the number of people using personal password
    management suites like KeePass and Password Safe and LastPass and
    1Password, all of which offer automatic generation of unique random
    passwords and many of which default to making those 20 characters

    Since your back end should be salting and hashing these passwords
    anyway, which results in fixed-size fields in the database regardless
    of input password length, there should be no reason at all why you
    need to impose a maximum length limit anywhere near as low as 20
    characters. But if you insist on doing so, the site should *say what
    it is* so that people using password generators can set them

    > Both the password and login issues are still  currently being
    > tested, is it convenient for me to contact you by phone tomorrow
    > to udpate you on this result?

    No, I won't be at the school tomorrow (I work there Thursdays and
    Fridays only). I would prefer to be kept informed by email.

    Thank you

  • @flabdablet said:

    Round 2! Apparently just being cranky at them has pushed things along a little.

    Reasoned crankiness - along with noises that:

    1. the remainder of their business is exceptional quality but this particular aspect lets them done VERY badly 
    2. if it's a deliverable service and it's not up to scratch, it will cause them to lose customers (if only yours)

    .. tends to work.

     I'm amazed at just how many companies there are out in meatspace that perform pretty well yet their webshite is a steaming pile of crusty wino gusset. Schizophrenic vision, or something.

  • So they've been working on it, and I can no longer 500 their server simply by attempting to log in, which is progress.

    Just for shits and giggles I monitored a login using Wireshark, and found that

    • login ID and password are both sent as POST parameters in plain text
    • there is no way to make the site do this via HTTPS

    Please, Higher Power, help me keep resisting the urge to inject SQL. It's been days since I've used and I promised my mother I'd stay clean this time.

  • @flabdablet said:

    Please, Higher Power, help me keep resisting the urge to inject SQL.

    Are you sure they even use a database? Maybe the website is feeding a terminal emulator. You should try CICS injection.

  • I dunno, the 500 looks pretty enterprisey.


    HTTP Status 500 -
    type Exception report
    description The server encountered an internal error () that prevented it from fulfilling this request.
    note The full stack trace of the root cause is available in the Apache Tomcat/5.5.20 logs.
    Apache Tomcat/5.5.20

  • @flabdablet said:

    I dunno, the 500 looks pretty enterprisey.

    XML error on Tomcat. How unusual.

  • Round 3: The Final Resolution

    On 19 June 2012 09:21, <supportperson@vendor.example.com.au> wrote:

    > I've heard from IT this morning regarding the database issues
    > they've been working on. As a result of the new change additional
    > users should now be able to create addtional users via the super
    > user's account administration page without reports of server errors.
    > Please advise me how this goes.

    I have just now done the following things successfully:

    1. Log in as "redacte" (super user) and change the super user login
    ID to "redacted" with a new 15-character random password.

    2. Log out, then log in as "redacted".

    3. Change the login ID for Additional Member 1 from "xyzredacted"
    to "xyz.redacted" without changing the password.

    4. Log out, then log in as "xyz.redacted".

    5. Log out, then log in as "redacted".

    6. Change the login ID for Additional Member 2 from "smredacted" to
    "staffmember.redacted" with a new 15-character random password.

    7. Log out, then log in as "staffmember.redacted".

    8. Log out.

    So all seems well, and I have notified Competent Reseller from XYZ
    Excellent Supplier that she can now log in as "xyz.redacted" and
    enter our purchase details.

    The first invoice for our recent round of purchases was dated 25-May,
    which doesn't give her much time to do this before the 30-day window
    closes. Are you able to allow us extra time in view of how long it's
    taken to get our registration to work?

    > In addition to this I feel extending the password field in the database
    > is a valid concept which I will also forward to IT.

    You might also care to mention that neither enforcing the use of
    unsecured HTTP for login requests nor embedding customer passwords in
    those requests as clear text are consistent with your brochure's claim
    that "All information provided in the registration will be treated as

    Thank you for your ongoing efforts to resolve these issues. It can't
    be easy being the person whose job it is to defend an IT department
    apparently incapable of getting fundamental stuff like this even
    vaguely right.


    From: supportperson@vendor.example.com.au
    21 Jun (1 day ago)

    Good morning Flabdablet,

    I'm pleased to hear the database issues have been resolved. In regards
    to the outdated tax invoices, Competent is aware of the procedure involved
    in getting these approved. I don't see this being an issue as this was not
    your fault in this case.



    And I've just heard from Competent Reseller that all our purchases have now been successfully entered, so that's an end to all our troubles, apparently.

    Might check back in a month or so to find out whether the name-reservation race condition and the total lack of encryption around the login process were also considered "valid concepts" and "forwarded to IT". Anybody willing to take a punt either way?

  • This thread is like reading Mandrake cartoons in a daily newspaper and now you're saying the next episode will happen in one month only. Without this entertainment I guess I'll have to switch to the Weather Channel and watch in disbelief as the temperature moves up or down a degree every once in a while.

Log in to reply

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.