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
intervention?I will be happy if you can assure me that IT has removed its
> 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
fail?
Thanks
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.
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.
Regards
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.
Regards
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
watch*.
> 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
problem.
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.
Regards
-
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.
Regards,
Mailbot
-
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:
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
long.
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
appropriately.
> 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:
- the remainder of their business is exceptional quality but this particular aspect lets them done VERY badly
- 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 message description The server encountered an internal error () that prevented it from fulfilling this request. exception java.lang.NullPointerException java.io.StringReader.<init>(StringReader.java:33) au.com.redacted.Core.XML.parser.XMLParser.parse(XMLParser.java:59) au.com.redacted.Core.XML.parser.XMLParser.parseToNode(XMLParser.java:71) au.com.redacted.Core.XML.datastructures.XML.appendXML(XML.java:383) au.com.redacted.Projects.K12.Registration.web.RegisterUserPrint.getSuperUserXML(RegisterUserPrint.java:117) au.com.redacted.Projects.K12.Registration.web.RegisterUserPrint.getXML(RegisterUserPrint.java:97) au.com.redacted.Projects.K12.Registration.web.RegisterUserPrint.service(RegisterUserPrint.java:62) javax.servlet.http.HttpServlet.service(HttpServlet.java:853) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) note The full stack trace of the root cause is available in the Apache Tomcat/5.5.20 logs. Apache Tomcat/5.5.20
-
-
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
confidential".
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.
Regards
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.
Regards,
SupportpersonAnd 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.
