Comment On Avoiding the dreaded Refresh

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.

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.

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.

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 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]

 

Anonymous:

Brilliant, absolutely brilliant.

You didn't run spellcheck.  It's "brillant".

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...

Yeah, like Google Maps. :)

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.

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.   

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.

Wow, was this fixed to work in firefox now?

MY EYES!!! MY EYES!!!



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

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

It looks like this code was beat to death with a stupid stick and IT management by the whole damn forest.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.  

Reminds me of a favorite quote

An organisation that treats its programmers as morons
will soon have programmers that are willing and able
to act like morons only.

Which reminds me of yet another

 

Programming today is a race between

software engineers striving to build bigger

and better idiot-proof programs, and the

Universe trying to produce bigger and

better idiots. So far, the Universe is winning. 

 

Enough of this I need a long weekend

 

 

 

 

 

Hope no one views the source. [connection string]

Anonymous:

Wow, was this fixed to work in firefox now?

It's always worked in firefox.

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.

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.

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

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.

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

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.

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.

Was "object" tag for ActiveX or Java applet?

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

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.)

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?

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.

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...

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.

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.

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.

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)">

Ya!! the RDS tutorial is INSANE!!!

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.

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.

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 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.

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

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

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

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.

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   

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?

:'(



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



WTF?

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.

 

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



cu

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.

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

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>.