• (cs)

    I know that this is a fairly standard "Developer response", but I don't understand how companies that lack project managers of decent intelligence who know how to say "that is a dumb request it adds no value to our project yet will take lots of time to implement, let alone might be a security hazard" manage to stay in business.

  • (cs)
    let's stay best friends forever


    You know, you'll make more friends if you stop with the reposts!!

    Just kidding of course.  It's the last day I'll do that!  Huzzah for Fridays!  Everyone have a good weekend.
  • vdboor (unregistered)

    Brilliant, absolutely brilliant.

    I'll take this example to my work after the holidays.

    I suppose we don't have mention this does: a) does not work in firefox. b) when user tries to find out why they discover this crap, and c) realise how they can log into their database. and d) either copies the contents, steals the database design (if you even want it with such crap) or decides to drop all tables.

    not to mention all private sensitive data from the resultsets is transfered in the public between clients and servers.

  • (cs)

    This sounds similar to an internal web app I worked with in the past.  The original developer was so in lust with XML, but still wanted to have "non flashing" and "non reloading".   So guess what?  Client-side SQL statements are sent via Javascript to numerous ASP pages, which in turn call COM objects, which simply take the embedded SQL, execute it, convert it MANUALLY back into XML and send that back to the client.

    The client side page that loads was well over 10,000 lines of sh** thanks to all the Javascript and business logic embedded onto a single page.  I made a pile of cash maintaining that thing when I could have rewritten it in 3-4 weeks in Delphi or C#.NET, alas it was deemed too complex by the management to discard.

    Ugh.

    What was funnier was that I wrote a simple Delphi 5 app with a single DevExpress that aggregated the data that the web client monstrosity produced... in 30 minutes.  That "helper" app I wrote was supposed to demonstrate how quickly I could get rid of their existing app.  Instead, they are STILL using that horrible app and also using the helper app I wrote.

    It's always better to just avoid car wrecks like that and allow the company to experience a LOT of pain so they'll make the proper architecture decisions.

  • Anonymous (unregistered)

    I don't get!?!?

    I've never seen anything like that... What is SQL doing in client side code? Is this the WTF? Who does it even work? Is it an ActiveX thing? And What is wrong with blinking, that's how browsers work.

    My head is about to explode [:O]

     

  • (cs) in reply to vdboor
    Anonymous:
    Brilliant, absolutely brilliant.


    You didn't run spellcheck.  It's "brillant".
  • smith (unregistered)

    i guess using something like AJAX would make too much sense!

    but, i can only think of the perversions that will come from AJAX being widely used...

  • (cs) in reply to smith

    Yeah, like Google Maps. :)

  • (cs) in reply to christoofar

    Ugh.

    I like The Daily WTF, it makes me feel good about myself. Even though I have only three years of education and no real experience, I'm still way ahead of some of the boneheads out there.

  • (cs)

    I wouldn't be able to work as a developer for that company.  There is a stupidity limit that I have in regards to those kinds of requests.  That limit has been exceeded here.

    The client side Sql has to be one of the worst ideas ever.   



  • Andrei (unregistered) in reply to RobbieGee
    RobbieGee:
    Ugh. I like The Daily WTF, it makes me feel good about myself. Even though I have only three years of education and no real experience, I'm still way ahead of some of the boneheads out there.


    Amen.
  • Andrei (unregistered) in reply to Andrei

    Wow, was this fixed to work in firefox now?

  • (cs)

    MY EYES!!! MY EYES!!!

    The page doesn't blink - because I've been struck blind!

  • (cs) in reply to RobbieGee
    RobbieGee:
    Ugh. I like The Daily WTF, it makes me feel good about myself. Even though I have only three years of education and no real experience, I'm still way ahead of some of the boneheads out there.


    It is sad that the bar is so low.

    Sincerely,

    Gene Wirchenko

  • (cs) in reply to Maurits

    <FONT face=Arial><FONT size=2>It looks like this code was beat to death with a stupid stick and IT management by the whole damn forest.</FONT></FONT><FONT face=Arial><FONT size=2>It amazes me that any company would allow connection strings, server names, and select statements client side.  Can we say SQL injection?  But then I guess these guys think that a SQL injection is a shot they give there servers to prevent hacking.  </FONT></FONT>

    <FONT face=Arial size=2>Reminds me of a favorite quote</FONT>

    <FONT face=Arial>An organisation that treats its programmers </FONT><FONT face=Arial>as morons
    will soon have programmers that </FONT>    <FONT face=Arial>are willing and able
    to act like morons only.</FONT>

    <FONT face=Arial><FONT size=2>Which reminds me of yet another</FONT></FONT>

     

    Programming today is a race between <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

    software engineers striving to build bigger<o:p></o:p>

    and better idiot-proof programs, and the <o:p></o:p>

    Universe trying to produce bigger and <o:p></o:p>

    better idiots. So far, the Universe is winning.<FONT face=Arial size=2> </FONT>

    <FONT face=Arial size=2></FONT> 

    <FONT face=Arial size=2>Enough of this I need a long weekend</FONT>

     

    <FONT face=Arial size=2></FONT> 

    <o:p><FONT face=Arial></FONT></o:p> 

     

     

  • (cs)

    Hope no one views the source. [connection string]

  • (cs) in reply to Andrei
    Anonymous:
    Wow, was this fixed to work in firefox now?


    It's always worked in firefox.
  • (cs) in reply to Matt B

    <font size="2">

    Matt B:
    I know that this is a fairly standard "Developer response", but I don't understand how companies that lack project managers of decent intelligence who know how to say "that is a dumb request it adds no value to our project yet will take lots of time to implement, let alone might be a security hazard" manage to stay in business.


    I worked for a company that also banned the refresh 'blink'. What a bunch of asshats.
    I worked there for 6 months and wasted so much time on that one non-feature, I could have had the actual application finished (it was just their in-house intranet; no external clients!).

    Instead, they abandoned the browser completely and rearchitected to winforms and client/server. I hear they're still working on it (it's now almost 2 years later).

    Needless to say, I got the hell outta there.</font>
  • (cs)

    Hey now, that was really Microsoft's best idea for putting data on the web circa 1997 or so.

    RDS Tutorial
    I think they apologized later.

  • David Wilson (unregistered)

    As a counter-WTF.. I wonder if it would be possible to lock down SQL server sufficiently enough to allow clients to really connect in like that.. if you hid all the data access behind some fairly contrived stored procedures (eg: www session authentication in sql :D), could this actually be done in a way that wasn't completely insane?

    I'm not sure whether I'm trolling here or not.. I'm actually quite intrigued. :P

  • bkool (unregistered)



    Jake,     if you knew the right solution why wouldn't you speak up? Come up with a demo that shows a few pages w/ asynchronous javascript calls and hidden calls to the database.  They can see that it's non-refreshing AND slightly more secure. I can understand inheriting crap code but if you're the one involved in the project, wtf.



    								</span>
  • Muck Jones (unregistered) in reply to RobbieGee

    Just wait, baby.... just wait...

  • (cs) in reply to David Wilson
    Anonymous:
    ... possible to lock down SQL server sufficiently enough to allow clients to really connect in like that.. if you hid all the data access behind some fairly contrived stored procedures (eg: www session authentication in sql :D), could this actually be done in a way that wasn't completely insane?


    Yes, this is very possible.  But giving global SELECT permission is just asking for trouble -- you wouldn't want one client to be able to see anyone else's records.  And of course INSERT / UPDATE / DELETE permission is even worse.

    But as long as all the permissions are applied on the stored procedures - and each stored procedure includes @Username and @Password parameters - sure.
  • (cs) in reply to bkool

    Anonymous:
    Jake, if you knew the right solution why wouldn't you speak up? Come up with a demo that shows a few pages w/ asynchronous javascript calls and hidden calls to the database.  They can see that it's non-refreshing AND slightly more secure. I can understand inheriting crap code but if you're the one involved in the project, wtf.

    I absolutely agree, but I wasn't involved in this project, it was just one that the company did while I was there.  Alex was involved in the project, though he wouldn't do anything remotely like this (if you couldn't tell by now, he's a HUGE best practices nut), I don't think he saw the code until the project was finished.  Plus there's only so much you can get from arguing and pointing out serious security flaws.

    I alerted my boss then Alex about the "admin=false" in the querystring of another app we made.  Alex wrote a WTF about if you check the archives.  However, once the work is done, the budget depleted, the dust settled, if everything works, then we don't want to maintain it until we get more money.  It's nice to think that I could go back and fix it, but realistically, there's not much I can do.

  • coder (unregistered) in reply to Maurits

    Was "object" tag for ActiveX or Java applet?

    I am guessing ActiveX. Either way it's WTF!

  • (cs) in reply to christoofar
    christoofar:
    This sounds similar to an internal web app I worked with in the past.  The original developer was so in lust with XML, but still wanted to have "non flashing" and "non reloading".   So guess what?  Client-side SQL statements are sent via Javascript to numerous ASP pages, which in turn call COM objects, which simply take the embedded SQL, execute it, convert it MANUALLY back into XML and send that back to the client.

    The client side page that loads was well over 10,000 lines of sh** thanks to all the Javascript and business logic embedded onto a single page.  I made a pile of cash maintaining that thing when I could have rewritten it in 3-4 weeks in Delphi or C#.NET, alas it was deemed too complex by the management to discard.

    Ugh.

    What was funnier was that I wrote a simple Delphi 5 app with a single DevExpress that aggregated the data that the web client monstrosity produced... in 30 minutes.  That "helper" app I wrote was supposed to demonstrate how quickly I could get rid of their existing app.  Instead, they are STILL using that horrible app and also using the helper app I wrote.

    It's always better to just avoid car wrecks like that and allow the company to experience a LOT of pain so they'll make the proper architecture decisions.


    I think I know that company.  I was on an assignment at a company a lot like that.  We had 2 developers to maintain massive amounts asp sh** like that.  The project manager wasn't interested in replacing it and if we did any more than 15 minutes code each day, the PM would have to work all weekend.  (Don't ask, I don't know why either.)
  • (cs) in reply to Maurits
    Maurits:
    Anonymous:
    ... possible to lock down SQL server sufficiently enough to allow clients to really connect in like that.. if you hid all the data access behind some fairly contrived stored procedures (eg: www session authentication in sql :D), could this actually be done in a way that wasn't completely insane?


    Yes, this is very possible.  But giving global SELECT permission is just asking for trouble -- you wouldn't want one client to be able to see anyone else's records.  And of course INSERT / UPDATE / DELETE permission is even worse.

    But as long as all the permissions are applied on the stored procedures - and each stored procedure includes @Username and @Password parameters - sure.


    Easier way around it than that.  For anyone who really only needs to see a particular section of the database, make views built from a limited set of the data.  After that, give em read only permission on the data.  If INSERT/UPDATE/DROP is needed, that would definitely take a bit more work, and could possibly require a look at how the database is set up in general.  Ultimately, for read only access it's a simpler way of handling it than creating a bunch of stored procs.

    I did understand that correctly, didn't I?
  • (cs)

    It has a certain charm, but I prefered the website generated from stored procedures.  Ah, that one is a classic, and in a sick twisted, perverted kinda way, it even makes sense.  This one, however, just begs for a few drop tables.

  • (cs) in reply to JThelen
    JThelen:
    For anyone who really only needs to see a particular section of the database, make views built from a limited set of the data.  After that, give em read only permission on the data
    ...
    I did understand that correctly, didn't I?


    Not really, no.

    Consider a schema with two tables:

    Customers (CustomerID, Username, Password, ...)
    Orders (OrderID, PlacedByCustomerID, Amount, ...)

    To allow customers to view their orders - and ONLY their orders - I'm suggesting creating a stored procedure

    EXECUTE Orders_View @Username, @Password

    Which would prevent a customer from changing the SQL to view other users' orders.

    To do it your way, you'd need to create an infinite series of views:

    ...
    CREATE VIEW Orders_ByCustomer38 AS SELECT * FROM Orders WHERE PlacedByCustomerID = 38
    ...

    and then create a database-level username and password[1] specific to customer #38...

    and then give that username and password SELECT access to that view.

    [1] And don't use a reverse-engineerable method of generating these, or the customer will just reverse engineer it and change the DB connection string...
  • (cs) in reply to JThelen
    JThelen:
    Maurits:
    Anonymous:
    ... possible to lock down SQL server sufficiently enough to allow clients to really connect in like that.. if you hid all the data access behind some fairly contrived stored procedures (eg: www session authentication in sql :D), could this actually be done in a way that wasn't completely insane?


    Yes, this is very possible.  But giving global SELECT permission is just asking for trouble -- you wouldn't want one client to be able to see anyone else's records.  And of course INSERT / UPDATE / DELETE permission is even worse.

    But as long as all the permissions are applied on the stored procedures - and each stored procedure includes @Username and @Password parameters - sure.


    Easier way around it than that.  For anyone who really only needs to see a particular section of the database, make views built from a limited set of the data.  After that, give em read only permission on the data.  If INSERT/UPDATE/DROP is needed, that would definitely take a bit more work, and could possibly require a look at how the database is set up in general.  Ultimately, for read only access it's a simpler way of handling it than creating a bunch of stored procs.

    I did understand that correctly, didn't I?


    How about using JavaScript to call (web) server-side code (cgi/asp/whatever) that will make the SQL queries (in the comfort and security of its own realm) and generate output which would be received back by the calling client, and display it?  Somewhat of a poor-man's version of XMLHTTP+Javascript, but without the XML (or with it, but I'm assuming that they were avoiding it for some reason.)  Perhaps using iFrames, or even hidden <FRAME> tags to make GET requests to the web server, with cross-frame communication...

    I dunno, there are plenty of cheap, quick 'n dirty ways of getting data back and forth between the server and client without making the client the keeper of the keys.  Sure they're clunky, ugly and maybe even hard to maintain -- but not any more than the WTF here, and certainly more secure!

         -dZ.
  • (cs)

    Oh, I almost forgot -- (and to cast a farewell to this week of Classic WTFs once and for all...)

    "What is this Best Practices that you speak of?"

        dZ.

  • (cs) in reply to SwinePearls
    SwinePearls:
    Hey now, that was really Microsoft's best idea for putting data on the web circa 1997 or so.

    RDS Tutorial


    OMG! That's insane!!

    SwinePearls:

    I think they apologized later.


    I sure hope so.  Some people get their hands chopped off for much lesser transgressions.  Jeeeez.

        -dZ.

  • (cs)

    Why couldnt they do some thing with page transitions for IE ?
    It would blink in Fx but at least it would work.


    http://www.jansfreeware.com/articles/ie-page-transitions.html
    http://msdn.microsoft.com/workshop/author/filter/filters.asp

    All it would take is this :

    <meta http-equiv="Page-Enter" content="progid:DXImageTransform.Microsoft.Pixelate(Duration=1)">
    <meta http-equiv="Page-Exit" content="progid:DXImageTransform.Microsoft.Pixelate(Duration=1)">

  • Davey (unregistered) in reply to DZ-Jay

    Ya!! the RDS tutorial is INSANE!!!

  • coding slob (unregistered) in reply to Davey

    I used to work for a "dot Com", they outsourced development of their "one of the kind" web product to one of those consulting company, which they didn't pay for, instead consulting company used men hours spent on this project as "investment" in .com to get some stock options, wtf?.


     So, of course consulting company put their "top" people on this project. Their design pattern was cache everything on client side in hidden fields. Sometimes entire tables would be cached. Then use JS to parse cached data to populate controls on the page, or even worse; on submit document.write the entire page, of course all hidden fields and their values had to be "recached" through document.write. So JS had thousands of lines of "document.write". Needless to say, when we got sourcecode from them, it was a nightmare to maintain, I am not even going to mention all the JS cross-browsers issues. Well, half of the JS didn't work properly in all IE versions [:'(], So after struggling with this JS crap. it made more sense to rewrite this things rather than continuing to maintain it. Of course .com went out of business before we finished the release version.

  • Tobias Brox (unregistered) in reply to einstruzende
    einstruzende:

    The client side Sql has to be one of the worst ideas ever.   


    I did something similar some years ago (the users could in theory build up arbritrary SQL queries, including updates, inserts and deletes through the post data) - with all the ACL handled by the DBMS.  I don't think it was such a stupid idea, after all.
  • Mirandir - king of WTF-making (unregistered)

    If you don't wan't the webpage to blink use Flash!!

    Otherwise you could probably achieve it by showing and hiding iframes.

    /Mirandir

  • Jim Howard (unregistered) in reply to Mirandir - king of WTF-making

    You know, I still write old fashioned windows applications, the kind that end in "exe", and you double click on them to start them up.

    If I can do it, its not that hard. 

    I have to wonder why people spend so much effort trying to force the camel of an entire desktop application through the needle of an internet connection.

  • (cs) in reply to Jim Howard

    What I've been wondering, and I can imagine is true, is: will this actually work if the DBServer is in a different domain from the webserver?

    If not, it would cut down on the risk. Although I have written a nice piece of IE javascript which allows me to view the current state of the page and alter it (it's nice to see how altering a hidden field changes behaviour on some websites). So if I altered the SQL that would probably work anyway. Eew.

    Drak

  • Thomas Magle Brodersen (unregistered) in reply to DZ-Jay

    How about linking to an external javascript that is generated on the fly? (Or will it be cached?)

  • (cs) in reply to Jim Howard

    Anonymous:
    You know, I still write old fashioned windows applications, the kind that end in "exe", and you double click on them to start them up.

    If I can do it, its not that hard. 

    I have to wonder why people spend so much effort trying to force the camel of an entire desktop application through the needle of an internet connection.

    Amen

  • (cs) in reply to Maurits
    Maurits:
    JThelen:
    For anyone who really only needs to see a particular section of the database, make views built from a limited set of the data.  After that, give em read only permission on the data
    ...
    I did understand that correctly, didn't I?


    Not really, no.

    Consider a schema with two tables:

    Customers (CustomerID, Username, Password, ...)
    Orders (OrderID, PlacedByCustomerID, Amount, ...)

    To allow customers to view their orders - and ONLY their orders - I'm suggesting creating a stored procedure

    EXECUTE Orders_View @Username, @Password

    Which would prevent a customer from changing the SQL to view other users' orders.

    To do it your way, you'd need to create an infinite series of views:

    ...
    CREATE VIEW Orders_ByCustomer38 AS SELECT * FROM Orders WHERE PlacedByCustomerID = 38
    ...

    and then create a database-level username and password[1] specific to customer #38...

    and then give that username and password SELECT access to that view.

    [1] And don't use a reverse-engineerable method of generating these, or the customer will just reverse engineer it and change the DB connection string...


    I understood what you were getting at, however you took a single read only user and blew it out a bit further than what I'd have done.

    You can have a single user on the database with read access, and pass in credentials from the app which are used to generate querys.  It's not difficult to do, keeps stored procedures off the database[1], and is easy to maintain, and not a kludge if done properly.

    [1] My main reason for wanting to avoid using stored procedures is that *most* enterprise web architechtures won't let you use them.  I'm currently working on a project where your solution would get the project banned from the framework;  mine is the currently accepted solution.
  • G (unregistered) in reply to Mirandir - king of WTF-making
    Anonymous:

    If you don't wan't the webpage to blink use Flash!!

    Otherwise you could probably achieve it by showing and hiding iframes.

    /Mirandir

     

    you can do similar stuff using AJAX

     

    http://en.wikipedia.org/wiki/AJAX   

  • (cs) in reply to Jim Howard
    Anonymous:
    You know, I still write old fashioned windows applications, the kind that end in "exe", and you double click on them to start them up.

    If I can do it, its not that hard. 

    I have to wonder why people spend so much effort trying to force the camel of an entire desktop application through the needle of an internet connection.


    My company does this too.  The main argument I would be able to understand for taking this approach is that a browser application can theoretically run on any platform (I know making this work is nontrivial).  But our app only runs under IE, and I'm sure it's not alone in that regard.  So much for that argument.  What's left?

  • Firefoxer (unregistered) in reply to Matt B

    :'(

    This site has no business criticizing anyone about shitty code. Ad images and text appear on top of the article text.

    WTF?

  • coding slob (unregistered) in reply to stevekj

    stevekj:
    Anonymous:
    You know, I still write old fashioned windows applications, the kind that end in "exe", and you double click on them to start them up.

    If I can do it, its not that hard. 

    I have to wonder why people spend so much effort trying to force the camel of an entire desktop application through the needle of an internet connection.


    My company does this too.  The main argument I would be able to understand for taking this approach is that a browser application can theoretically run on any platform (I know making this work is nontrivial).  But our app only runs under IE, and I'm sure it's not alone in that regard.  So much for that argument.  What's left?

    Well, ease of deployment and updates. Also one could argue duration of development and cost.

     

  • (cs) in reply to Firefoxer

    @firefoxer: No probs here with v1.0.6 on XP, however, try to reload and the ad will probably be placed correctly.

    cu

  • (cs) in reply to eagle
    eagle:
    @firefoxer: No probs here with v1.0.6 on XP, however, try to reload and the ad will probably be placed correctly.

    cu


    At this point, anyone still bitching about the site itself being a WTF is a troll.  The fact that he's not logging in says loads about that.

  • (cs) in reply to JThelen
    JThelen:


    At this point, anyone still bitching about the site itself being a WTF is a troll.  The fact that he's not logging in says loads about that.



    OK, next time I'll troll vote, instead of answering. However, I found this reloading tip given in another thread by someone else helpful, and wanted to pass on the favor/knowledge. cu
  • (cs) in reply to eagle
    eagle:
    JThelen:


    At this point, anyone still bitching about the site itself being a WTF is a troll.  The fact that he's not logging in says loads about that.



    OK, next time I'll troll vote, instead of answering. However, I found this reloading tip given in another thread by someone else helpful, and wanted to pass on the favor/knowledge. cu


    Understandable.  I find that any page rendering error I've had with any site, not just this one, can be fixed with a refresh unless the site is simply designed to be broken in <insert browser here>.

Leave a comment on “Avoiding the dreaded Refresh”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article