• (cs) in reply to Ben

    Obviously jeremyp.asp contains a lot of user validation as well.

    It is unlikely that the hard coded names are only once coded in this application.

    Each page must have its own list of usernames, otherwise it would be easy to maintain and you wouldn't be able to write that many hours.

  • boicy (unregistered) in reply to The Anonymous Coward
    Anonymous:
    Anonymous:

    This is actually concise code that clearly achieves its intent.  I suspect any alternative solution would introduce new costs, and I'm not sure what the benefits would be.  The WTF in the system is probably that ronaldt.asp and special.asp are needless reimplementations of the default ASP, but since that's not what is actually posted, it's hard to tell.

    Concise?  Hardly.

    Look, the optimist in me hopes you're joking, but my inner pessimist insist on responding anyway.  If you don't see what's wrong with this, get as far from the software business as you possibly can.  You are a danger to yourself and others.

    I am beyond tired of working with folks who "can't see the benefit" of good design and maintainable code.  When it's time to do the Hard Work of making code maintainable, they just can't see how the easy way would ever be a problem; yet then when it's time to maintain the code, they're the first ones moaning about how hard it would be to change this or fix that; but of course, the problem isn't the code, so it must be these unreasonable new requirements!

    WTF!



    Well, I don't know about that... what about TDD and writing the "simplest possible thing that could work"? It's certainly simple, it certainly works (we assume).

    If you had to implement it again or if the list of users became unmanageable then you could argue it's not the right solution, but that's a different story (geddit? _groan_).

    Now I'd just like to see the tests the dev wrote. They did write tests right? ;-)
  • Guran (unregistered) in reply to boicy

    I'll have to side (partly) with the not-so-bad crowd here.

    I've developed by-the-book scalable ("enterprise" if you will) solutions, one-off hacks and everything in between. One thing I've learned the hard way, is that when you design a small app to be flexible and extendible in one direction, someone always wants it to flex and extend in a 90 degree angle to where you anticipated. The built in flexibility, otoh is never used. Old Murphy and his laws again.

    I've maintained a very extensible, multitiered system, where the access model was so flexible that it could do practically anything. Guess what? That flexibility ate system resources like no tomorrow, but the customer STILL managed to order things that the access model wasen't designed to do.

    Do I find todays WTF ugly? Yes.
    Would I write code like that? No way.
    Could I improve it dramatically in no time? Sure.

    But at least you could pull any coder from the street to make changes to that page. Better that than some "flexible" supersolution, that still requires some extra hacks to work, where future maintainers has to know both the flexible enerprise backbone and the hacks placed there to bend the flexible solution backwards.

  • (cs) in reply to GalacticCowboy
    GalacticCowboy:

    Anonymous:
    The real WTF here is that they use VBScript

    Yes...  sort of.  It's ASP - VBScript-like syntax is all it supported.

     

    Which is of course nonsense.  JScript is supported out of the box (and has much nicer syntax and is all round a better language). And you can add any number of third-party languages, such as perl or python.  All within ASP.

     

  • Anonymous (unregistered) in reply to marvin_rabbit

    marvin_rabbit:
    Anonymous:
    I developed this system. It's pretty damn good in my opinion.

    Paul Bean

    (formerly Paula Bean, I had a sex change operation)

    I don't believe that you could have done that.  I've seen some of your code, Paul(a), and this goes way beyond your ability.

    If the original Paula Bean post is to be believed, we seen ALL of her code

  • Tragomaskhalos (unregistered) in reply to Pyromancer

    Anonymous:
    they sure are optimistic-they assume these guys will not quit or switch jobs [:D]

    I suppose this happens:

    "Hi Greg, welcome aboard. Your user name will be "RonaldT". Why ? Er, well we had to let Ron go (he was hiring a lot of really stupid programmers), but the system seems kind of fond of his name for some reason ...."

  • (cs) in reply to Tragomaskhalos
    Anonymous:

    Anonymous:
    they sure are optimistic-they assume these guys will not quit or switch jobs [:D]

    I suppose this happens:

    "Hi Greg, welcome aboard. Your user name will be "RonaldT". Why ? Er, well we had to let Ron go (he was hiring a lot of really stupid programmers), but the system seems kind of fond of his name for some reason ...."



    This is harmless, so harmless. In my first job, I had to maintain an application that would only work* if installed in the directory /usr/wolfi (Wolfi is the abbreviation of Wolfgang, a German first name; actually the first name of the original team leader who had left long ago)
    Now how can I explain that to a customer?

    * "work" is an exaggeration, but it produced slighty less errors if installed there
  • MamboJoel (unregistered)

    Hum ... The UCase strategy is a bit anoying yes ... But the REAL WTF suspense behind this code to me is the Special.asp and ronaldt.asp pages : will they implement any of the *security* logic of this listing ? Two strategies :
    1. copypaste listing in pages, replace response.redirect by response.end
    2. don't reimplement *security*
    Option 2 is more agile.

  • (cs) in reply to John Hensley
    Anonymous:

    Oh, I'm sure there are many people reading this forum who were once very impressed with themselves after adding a password to an 8-bit BASIC program using plaintext string comparison.

    Well, yes, but I was about 3 years old at the time.  There's no excuse for this kind of idiocy in anyone old enough to go to nursery school like the big boys.
  • (cs) in reply to makomk
    makomk:
    Anonymous:
    Alex Papadimoulis:
    Else
  session("grantaccess") = "SALES"
  session("showDebug") = "none"
End If



    my favourite part =)
    Heh - perhaps they give so little access to their salespeople that it doesn't matter if they give it out to random people. Or perhaps there were too many users in the sales department, and the author couldn't be bothered adding them all.

    As I always say (and have said before on this forum):

    Those who can, Do

    Those who can't, Sell

    and those who can't sell: Consult

     

  • PCBiz (unregistered)

    I'm sure they have realized by now that they will have a problem when the fire and hire people.  But then again I'm sure the will just assign the sam UserId to prevent from changing the code.   What was the guy thinking?  A true WTF!

  • (cs) in reply to Pyromancer
    Anonymous:
    they sure are optimistic-they assume these guys will not quit or switch jobs [:D]


    Think enterprisey!

    They sure can quit and other people could be hired instead of them. The successors will simply inherit the userids of the ancients. It's like Lamaism, there's always an incarnation of the DALAI_LAMA userid.
  • Steve (unregistered) in reply to The Uneducated Programmer

    Partly self-taught, I've worked with horrible coders and excellent coders. You'll have to take my word for it, I guess, or not.
    In any case - it's atrocious in the small, the duplicated method calls, the logic spread all over the page, etc, etc. To say it needs refactoring is a serious understatement. We all see that. I'm trying to play devil's advocate and argue for why it's not so terrible. Basically, the authentication lives in one (messy) place. You can't reduce that down, even if it lives on a sticky note on your desk. It's a small enough file that you can read it and understand it without too much trouble (aside from the time you'll waste on the occasionally "why the @(#&$(* did he do this?"). It's not all that secure but it's not unlike things I saw more often on the old client-server systems. And the extra string functions are dumb but probably unnoticeable in practice. Not saying that I like it. Just that it's not nearly as WTF as some of the greats of the past.

  • Sam (unregistered) in reply to GalacticCowboy
    GalacticCowboy:

    Anonymous:
    The real WTF here is that they use VBScript

    Yes...  sort of.  It's ASP - VBScript-like syntax is all it supported.

     

     

    Not true -- ASP could be made to support a number of languages.  I used to create all my ASP pages using Perl.  Much easier and the pages tended to be smaller.

  • (cs) in reply to Sam

    Wow, I've now been called an idiot by no less than 6 people...  And also learned something about ASP *shudder*.

    So the real WTF is it that nobody EVER wrote books or articles for ASP that used anything besides VBScript.  It's not like MS (or anyone else) really went out of their way to point that out.  I inherited an ASP "application" and beat my head against a wall "learning" VBScript...  Coming from a C++ background, so JScript - or really anything at all - would have been massively better...  And my boss at the time (who really should have known better, except he was coming from a ColdFusion background) told us all that VBScript was the only language in ASP.  What the fuck did I know; I was a junior programmer who did what I was told...  [6]

  • (cs) in reply to GalacticCowboy
    GalacticCowboy:

    Wow, I've now been called an idiot by no less than 6 people...  And also learned something about ASP *shudder*.

    So the real WTF is it that nobody EVER wrote books or articles for ASP that used anything besides VBScript.  It's not like MS (or anyone else) really went out of their way to point that out.  I inherited an ASP "application" and beat my head against a wall "learning" VBScript...  Coming from a C++ background, so JScript - or really anything at all - would have been massively better...  And my boss at the time (who really should have known better, except he was coming from a ColdFusion background) told us all that VBScript was the only language in ASP.  What the fuck did I know; I was a junior programmer who did what I was told...  [6]


    Nah, just not well informed.  You can even use the ASP objects in Perl.  And you can mix-and-match languages: VbScript will support the JScript calling syntax, with a few nits for things like arrays.  Things like this make it a little less painful to interface with legacy code.
  • (cs) in reply to Guran
    Anonymous:

    I'll have to side (partly) with the not-so-bad crowd here.

    I've developed by-the-book scalable ("enterprise" if you will) solutions, one-off hacks and everything in between. One thing I've learned the hard way, is that when you design a small app to be flexible and extendible in one direction, someone always wants it to flex and extend in a 90 degree angle to where you anticipated. The built in flexibility, otoh is never used. Old Murphy and his laws again.

    I've maintained a very extensible, multitiered system, where the access model was so flexible that it could do practically anything. Guess what? That flexibility ate system resources like no tomorrow, but the customer STILL managed to order things that the access model wasen't designed to do.



    1. One-off hacks tend to become industry standards. The lifecycle goes like this: one-off hack/prototype -- temporary solution (will do until the next release) -- forgotten temporary solution (priorities always shifting until the original coder leaves the company) -- pivotal architectural decision (those who try to rewrite the system are unable to circumvent or remove your hack without people already used to the hack complaining or having another system topple over.)
    2. Flexible systems are never used in more than one way.
    3. Really flexible systems are for clueless consultants. I remember a consultant trying to convince me to use Spring MVC Framework for...wait for it...dynamic classloading!

    This whole issue of balancing between flexibility and usefulness is  admitted by even the most enthusiastic fans of the "mechanistic coding" to be an art unto itself.

  • (cs) in reply to biziclop
    biziclop:
    Anonymous:

    I'll have to side (partly) with the not-so-bad crowd here.

    I've developed by-the-book scalable ("enterprise" if you will) solutions, one-off hacks and everything in between. One thing I've learned the hard way, is that when you design a small app to be flexible and extendible in one direction, someone always wants it to flex and extend in a 90 degree angle to where you anticipated. The built in flexibility, otoh is never used. Old Murphy and his laws again.

    I've maintained a very extensible, multitiered system, where the access model was so flexible that it could do practically anything. Guess what? That flexibility ate system resources like no tomorrow, but the customer STILL managed to order things that the access model wasen't designed to do.



    This whole issue of balancing between flexibility and usefulness is  admitted by even the most enthusiastic fans of the "mechanistic coding" to be an art unto itself.



    IMO the most important issue with flexibility is to stop before your create a new language on top of an existing language, a new database on top of an existing database or anything like that.
    Once a system reaches the same flexibility like genuine source code, it's (in most cases) incredibly slow and extremely hard to maintain - because it is a new language, without the year-long specification and refinement process real-world language go through, without the IDEs and debuggers and other tools, without books and courses and magacine articles etc. If you need the full flexibility of a language - just embedd Lua or Python or VBA into your application.
  • (cs) in reply to ammoQ
    Anonymous:

    IMO the most important issue with flexibility is to stop before your create a new language on top of an existing language, a new database on top of an existing database or anything like that.
    Once a system reaches the same flexibility like genuine source code, it's (in most cases) incredibly slow and extremely hard to maintain - because it is a new language, without the year-long specification and refinement process real-world language go through, without the IDEs and debuggers and other tools, without books and courses and magacine articles etc. If you need the full flexibility of a language - just embedd Lua or Python or VBA into your application.


    This defines the upper bounds of flexibility, the lower bounds being "please, at least use a config file for things that are different in test and in production". But between these bounds anything can happen depending on the system architect's sanity.
  • jay (unregistered) in reply to wunderkind

    this is quite commical to read.  But then I read out loud to a co-worker and it was downright hilarious.  Give it an oral presenation for a serious laugh.

  • mcguire (unregistered) in reply to ammoQ
    ammoQ:

    In my first job, I had to maintain an application that would only work* if installed in the directory /usr/wolfi (Wolfi is the abbreviation of Wolfgang, a German first name; actually the first name of the original team leader who had left long ago)


    You know, I'd always wondered where ClearCase's "atria" came from....
  • A.Lurker (unregistered) in reply to Not Registered
    Anonymous:

    Am I the only one here who thinks this is not that bad? What is really the big difference between hardcoded usernames and a configuration file, especially for some internal application? Of course it could be done better, a lot better, but it could also be far worse.



    Nope.  Sure, it's cheezy, but it doesn't even come close to some of the willfully stupid, gratuitously complex, and marvelously poorly performing entries normally showcased here.  Your comment has the additional benefit of teasing out the arrogant puffdaddies lurking around, that can't understand that at the end of the day, what matters is whether something works, not whether it was abstracted to their satisfaction.   This is hideous code, and if there were 100,000 lines of it, it would be a maintenance disaster.  If the app controls money or protects lives, the security hole is dangerous.  But it looks like some departmental reporting system, so the business impact of a cheeseball hack is minimal. 

    This doesn't even come close to the idiocy of the old Andersen Consulting boys making us code WS-ONE for the value one. 
  • mcguire (unregistered) in reply to boicy
    Anonymous:

    Well, I don't know about that... what about TDD and writing the "simplest possible thing that could work"? It's certainly simple, it certainly works (we assume).


    That's one of the weaknesses of test-driven development.  You are not supposed to plan ahead (and in fact, someone raised on nothing but TDD probably wouldn't know how to plan ahead or what to plan for).  But some things, like maintainability, do not really show up on early feature lists, are a wee bit hard to test for, but require huge amounts of painful and expensive surgery plus a lot of duct tape to do later.

  • captain damage (unregistered) in reply to biziclop

    Todays is just not funny.

    I have to support a business critical app. which has that sort of "id is a manager" code everywhere. And I'm not allowed to make any fixes.

  • The Anonymous Coward (unregistered) in reply to boicy

    Anonymous:

    Well, I don't know about that... what about TDD and writing the "simplest possible thing that could work"? It's certainly simple, it certainly works (we assume).

    If you had to implement it again or if the list of users became unmanageable then you could argue it's not the right solution, but that's a different story (geddit? _groan_).

    Now I'd just like to see the tests the dev wrote. They did write tests right? ;-)

    Complexity (or simplicity, whichever way you look at it) is one of the most misunderstood concepts in software.  Just because it doesn't do anything fancy doesn't mean it's simple.  In terms of logic structure, this code is rather complex for what it's doing.  You can make it much simpler by employing more sophisticated coding techniques.  You might fnd this paradoxical; if so, I assert it's because we teach "complexity is bad" without ever properly defining what complexity means in that context.

    We don't know whether or not this code works, because we don't have the spec that tells us who should be able to do what, or the details of which page/privilege allows who to do what, or even the complete code.  If it does work right, we can only conclude that their QA is better than their development; but as the logic structure grows more complex (as we can see it already has and as we should assume it will unless/until refactoring occurs), the odds that it keeps working right for all inputs will drop off.

    As an aside, maintaining these names in the code is absolutely harder than in an external file.  To handle it this way, you have to navigate the code's logic structure to figure out where to make your change.  Plus an external data structure could be shared by other parts of the system.  Like... oh, I don't know, the subsystem that authenticates the user in the first place.  As it is, there's no telling how many pages have to be edited every time the user list changes.  And remember, 2 places to change the code isn't just twice as much typing; it's twice as much chance for a typo.

    For that matter, using an external data structure at least gives you the option to write an app to maintain the data in that structure should such become desirable.  (Ooooh... meta!)  As it stands, you can't (or at least, you shouldn't try).

    That says nothing of the increased risk when someone has to edit a code file to make a data change.  "Oh, this is just a simple change.  I'll just edit the file, save it to the production server, and then go home for the day."  And then make a syntax error that prevents the page from parsing.  It's important to realize that the human error rate is always greater than zero.

    Long story short (too late):  This isn't simple; it's lazy.

  • Justin Thomas (unregistered) in reply to The Anonymous Coward

    Why are some of you posting better solutions to this code? If your a programmer you should have a nice little laugh and probably a dozen other solutions that popped in your head the moment you looked at it.

    Hey Captain Obvious, WTF?

    Im just kidding, keep going im cracking up over here! [:D]

  • (cs) in reply to diaphanein
    Anonymous:

    Anonymous:
    Anonymous:
    This wtf reminds me of the hardcoded TI-83 BASIC program shells so prevalent in highschool. The ones that could be bypassed by pressing the 'ON' button...

    Oh, I'm sure there are many people reading this forum who were once very impressed with themselves after adding a password to an 8-bit BASIC program using plaintext string comparison.

    Those of us that were "hardcore" wrote the routine in ASM.

    I did once reduce myself to writing a TI-83 menu emulator to fool the teachers into thinking they were really clearing my RAM.  My first ASM app.  Boy could I pull some WTFs out of that code... What is this "stack" you speak of?

    Why go to all of the trouble?  Just put the stuff you want to keep from RAM to ARC, and it won't get deleted.  Change it back to RAM during the exam.

  • Brooks Moses (unregistered) in reply to John Hensley
    Anonymous:
    Oh, I'm sure there are many people reading this forum who were once very impressed with themselves after adding a password to an 8-bit BASIC program using plaintext string comparison.

    Hey, I once wrote a password protection for a LabView program that amounted to three on/off buttons with an "if(A and not(B) and C) then allowAccess" sort of logic, with the code plainly visible if one knew where to look.

    This was exactly the level of security that the system needed. See, the person I needed to lock out was a colleague who had blissfully ignored the warning in LARGE BRIGHT RED LETTERS directly over the "go" button than said "Make sure the hardware is reset before pushing 'go' or you will break the measurement probe," and had thereby broken the measurement probe.

    After that, we didn't have any problems. Anyone with enough basic common sense to use the system without breaking things was able to check the source code if they forgot the password, and it stopped everyone else.

  • Aaron K (unregistered) in reply to John Hensley
    Anonymous:

    Oh, I'm sure there are many people reading this forum who were once very impressed with themselves after adding a password to an 8-bit BASIC program using plaintext string comparison.


    Of course. The difference being that I was 12 at the time.
  • kevin h (unregistered) in reply to chrismcb
    chrismcb:

    Do you as the dev want to be bothered with the detail of updating the code in the html every time a person quits or is hired? Do you want some random secratary to be mucking around in your code? Is it going to really kill you to stick this into some sort of database (whether it is a real database or just a simple config file doesn't really matter)



    What I want, and what i get are two different things.  It does not matter how simple or easy some things are, if the corporate culture does not require a certain level of aptitude and skill beyond the programmer, the programmer will ALWAYS be the one updating the system.  period.  this goes beyond code in the real world.  Many of us accept the fact that we're programming for our selves on our internal apps.  the 'real' users just care about the paper it produces and they have not inturest how that happened or how it can happen more effeciently or with better business rules.
  • (cs) in reply to Paul Bean

    Paula Bean:
    I developed this system. It's pretty damn good in my opinion.

    Ahh, you left out  <FONT face="Courier New">Response.Redirect("brilliant.asp")</FONT>

    Alex:
    who wants to just add a stupid password to a stupid PDF document?
    At a previous place, I did just that. Wrote an Acrobat add-in that placed a standard lock-down password and standardized permission set for the PDFs that got posted. Good luck getting ahold of the acrobat sdk, since it is now hidden behind a subscription wall. But that is a wtf for another day.

  • Indrek (unregistered) in reply to Aaron
    Anonymous:
    In VBScript, using ADO, that is most likely just a recordset.  So rsGetUserID() isn't actually a method call, its more like retrieving a value from a collection. Thats one of the major problems with VB.  You can't tell between arrays (or indexers) and functions (or subs, bleh - cant believe they even distinguish between the two).  What a crappy language.

    Sillypants... unlike functions, you don't use parentheses when calling subs in VBScript.
    Of course rsGetUserID() is a recordset. Granted, if could've been made more evident (and efficient) by writing rsGetUserID.fields("foo").value but that might be too much to expect from that programmer.

    As for telling between arrays and functions, that's what you have naming conventions for. I for one appreciate that VBScript only has one type of parentheses (rather than three), especially since the other two types - {} and [] - are rather cumbersome on the keyboard layout I'm using.

    What's crappy language for you is a beautiful, logical and readable language for others.
    Now, feel free to post funny comments à la "egads, I think hell just froze over - someone called VBScript beautiful". Makes for cheap street cred.
  • The Anonymous Coward (unregistered) in reply to kevin h

    Anonymous:

    What I want, and what i get are two different things.  It does not matter how simple or easy some things are, if the corporate culture does not require a certain level of aptitude and skill beyond the programmer, the programmer will ALWAYS be the one updating the system.  period.  this goes beyond code in the real world.  Many of us accept the fact that we're programming for our selves on our internal apps.  the 'real' users just care about the paper it produces and they have not inturest how that happened or how it can happen more effeciently or with better business rules.

    Well, if what you do doesn't foster what you want, then you don't get to complain about what you get.  As soon as you take the attitude you've expressed here, it isn't "corporate culture"'s fault (even if it ever was in the first place); it's your own fault.

    It's inevitable that the user list will be updated by developers?  Hardly.  An awful lot of places flat-out wouldn't allow such a thing to happen in a production app.

  • Adam (unregistered) in reply to Not Registered

    Agreed. But I'll go further and suggest that engineers tend to fixate on getting something "right" too often, failing to realize this is probably "right" for this company.

    I imagine the response to this in many ways is indicative of the type of company(s) one works for. I often freelance for small to medium sized businesses that have no IT budget, and more importantly, need things done NOW so they can get back to struggling to make ends meet. That often means choosing a box solution that's underdeveloped and feature-starved enough that they can learn it in a few minutes, or rolling something out that's < 1000 lines of code.

    Coders that work in some cubicle all year and have a paycheck magically show up in their bank accounts every two weeks seem to be the first to critique the role of every other person in the company as "not getting it", when they themselves are sort of missing the point as to why they're there in the first place.

    If people leave the company, it's as simple as changing the name. If the company gets bigger, they'll have increased budget and time for  more sophisticated development.

    I for one think my peers need to stop being so darned elitist.

    Example: my personal photography site (awayfromkeyboard.com) is straight up html. no server-side scripting, no style sheets, just fonts and tables, just like the old days. It's ten times more fun to update, and more versitile to expand upon than any image gallery i've ever tried or written.

    Simple and elegant doesn't have to be complicated and bulky ;]

    </rhetoric>

Leave a comment on “Personal Personnel Authentication”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article