Disconnection String

« Return to Article
  • DB 2012-06-14 14:15
    Frist frist.
  • bewbs 2012-06-14 14:16
    second!

    .
    .
    .
    .not spam
  • Chronomium 2012-06-14 14:17
    The worst part is probably all the variables defined at the start of the code, especially those commented out. Only two of them are actually used, while the rest imply that some sort of heavy-duty database punching was attempted at some point.
  • DB 2012-06-14 14:18
    Anyway, I'm not a seasoned .NET programmer, but it's possible they were trying to avoid any potential issues with an empty or null return value.
  • M 2012-06-14 14:27
    Chronomium:
    The worst part is probably all the variables defined at the start of the code, especially those commented out. Only two of them are actually used, while the rest imply that some sort of heavy-duty database punching was attempted at some point.


    Maybe they tried putting all the connection strings in a database table?

    Not removing the obviously useless code is definitely a WTF. Also, who the heck is still using hungarian notation? sHere, sThere, sEverywhere.
  • KattMan 2012-06-14 14:32
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.

    Another possible way of getting them is through some service call, or maybe not getting them at all, let the service call access the data instead of the Asp.net application. Of course then you have the config file for the service that needs to be cleaned, but that is easier to point to a resource that has encrypted data instead of that resource being accessable from your web server.
  • honnza 2012-06-14 14:35
    M:
    Chronomium:
    The worst part is probably all the variables defined at the start of the code, especially those commented out. Only two of them are actually used, while the rest imply that some sort of heavy-duty database punching was attempted at some point.


    Maybe they tried putting all the connection strings in a database table?

    Not removing the obviously useless code is definitely a WTF. Also, who the heck is still using hungarian notation? sHere, sThere, sEverywhere.


    $var for jQuery objects? Kinda useful in weakly typed languages with similar types.
  • Scrummy 2012-06-14 14:42
    KattMan:
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.

    Another possible way of getting them is through some service call, or maybe not getting them at all, let the service call access the data instead of the Asp.net application. Of course then you have the config file for the service that needs to be cleaned, but that is easier to point to a resource that has encrypted data instead of that resource being accessable from your web server.


    Read the chapter on "Integrated Security."
  • emurphy 2012-06-14 14:56
    KattMan:
    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.


    Well, you can encrypt them in the config file, so I assume "this way" refers to this (unused) part:

    sColumns = "DataLink, Platform, Login, Password, Server, Database"


    Encryption is less of a big deal if you're dealing with an intranet app, or if the login only has read access to data that you want to share with the general public anyway.
  • Zylon 2012-06-14 15:10
    bewbs:
    not spam

    Let's agree to disagree on that.
  • HungarianProf 2012-06-14 15:14
    The Real WTF is that they do not have a string variable called HitCount (or anything that begins with Hit ...)
  • anony-mouse 2012-06-14 15:16
    KattMan:
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.

    Another possible way of getting them is through some service call, or maybe not getting them at all, let the service call access the data instead of the Asp.net application. Of course then you have the config file for the service that needs to be cleaned, but that is easier to point to a resource that has encrypted data instead of that resource being accessable from your web server.

    Haven't heard of Windows Authentication, eh?
    If you're using ASP.NET you're probably using MS SQL Server, in which the proper security model is to use Windows auth instead of a hard coded login/password.
  • Nagesh 2012-06-14 15:31
    The major atrocity here is that instead of simply getting the connection string by key ('ConnectionString' in this case), they first look it up by position. This makes no sense. Later, if the lookup-by-position works, then they get it by key.

    Um, I'm not fluent in VB.NET, but I can't see any "look it up by position" in the code snippet here. What they are doing seems to be to ask if the key at position 0 is 'ConnectionString', and then look it up by key. In all other cases -- including when 'ConnectionString' is the key in some non-zero position -- then they pretend that whatever the key at position 0 is, is the right connection string to use!

    That's much more of a WTF than doing something that works but in a unnecessarily roundabout way.
  • PedanticCurmudgeon 2012-06-14 15:41
    Nagesh:
    The major atrocity here is that instead of simply getting the connection string by key ('ConnectionString' in this case), they first look it up by position. This makes no sense. Later, if the lookup-by-position works, then they get it by key.

    Um, I'm not fluent in VB.NET, but I can't see any "look it up by position" in the code snippet here. What they are doing seems to be to ask if the key at position 0 is 'ConnectionString', and then look it up by key. In all other cases -- including when 'ConnectionString' is the key in some non-zero position -- then they pretend that whatever the key at position 0 is, is the right connection string to use!

    That's much more of a WTF than doing something that works but in a unnecessarily roundabout way.
    Did someone forget to switch sock-puppet names again?
  • Marc 2012-06-14 15:47
    I'm glad you said this, cause that's how I am reading it too.
  • Puzzles 2012-06-14 15:52
    M:
    Also, who the heck is still using hungarian notation? sHere, sThere, sEverywhere.

    Not only that, but only one of those three was actually declared as a string.

    "Dim x, y, z As String" creates z as a string but x and y as variants.
  • KattMan 2012-06-14 15:53
    anony-mouse:
    Haven't heard of Windows Authentication, eh?
    If you're using ASP.NET you're probably using MS SQL Server, in which the proper security model is to use Windows auth instead of a hard coded login/password.


    Not always, I've had Informix databases sitting behind and ASP.Net app.

    I agree, the inetuser should be the one with access and use authentication, but not always easy with certian databases.
  • lurch 2012-06-14 16:10
    Some Manager probably said

    "The Key is the Connection"

    And it was.

  • cdosrun 2012-06-14 16:22
    KattMan:
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.

    Another possible way of getting them is through some service call, or maybe not getting them at all, let the service call access the data instead of the Asp.net application. Of course then you have the config file for the service that needs to be cleaned, but that is easier to point to a resource that has encrypted data instead of that resource being accessable from your web server.


    Or you can encrypt the data in your web.config file.
  • KattMan 2012-06-14 16:27
    cdosrun:
    KattMan:
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.

    Another possible way of getting them is through some service call, or maybe not getting them at all, let the service call access the data instead of the Asp.net application. Of course then you have the config file for the service that needs to be cleaned, but that is easier to point to a resource that has encrypted data instead of that resource being accessable from your web server.


    Or you can encrypt the data in your web.config file.

    Yes you could, but try managing that from an global perspective, any time a password changes (remember PCI requires this) you need to update all the web configs you have in your system.

    Or you could have one file that has this that all the web.configs point to and simply change that one file.

    Granted, if your company is small enough to only have one site or service then this isn't a problem.
  • M 2012-06-14 16:27
    KattMan:
    anony-mouse:
    Haven't heard of Windows Authentication, eh?
    If you're using ASP.NET you're probably using MS SQL Server, in which the proper security model is to use Windows auth instead of a hard coded login/password.


    Not always, I've had Informix databases sitting behind and ASP.Net app.

    I agree, the inetuser should be the one with access and use authentication, but not always easy with certian databases.


    Agreed. A place I know uses asp.net backed by oracle everywhere. In fact, many of the separate oracle database servers were recently 'upgraded' to a single exadata server. Now all the apps get to share in the fun on those occasions when oracle flakes out, i.e. often.
  • Coyne 2012-06-14 17:25
    This is a total WTF. They should have looked up a key by position that would tell them the position of the database connection key. That way, they could move the database key by changing the first key.

    As it is, the database key is stuck forever at position 0. Where's the configurability?
  • hangy 2012-06-14 17:27

    sColumns = "DataLink, Platform, Login, Password, Server, Database"
    sTableName = "tblzApp"

    Aside from being out-of-context for this method - both variables are only being assigned to and are never read?!
  • Jeff 2012-06-14 17:44
    KattMan:
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.
    But, to decrypt them, you need the key. Where do you get that? From another file? Shouldn't that be encrypted too?
  • Bradley 2012-06-14 17:49
    Puzzles:
    M:
    Also, who the heck is still using hungarian notation? sHere, sThere, sEverywhere.

    Not only that, but only one of those three was actually declared as a string.

    "Dim x, y, z As String" creates z as a string but x and y as variants.


    Not since vb6.
  • Wyrm 2012-06-14 19:43
    It's even worse than I thought at first.
    If the connection string is not the first configuration line, it doesn't even return the first configuration value but the first key.
    Someone really has messed this up big time.
  • Jaime 2012-06-14 21:45
    Jeff:
    KattMan:
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.
    But, to decrypt them, you need the key. Where do you get that? From another file? Shouldn't that be encrypted too?
    DPAPI. It's secure against everyone except administrators or those with physical access to the box. Almost nothing can help you in those two cases.
  • Jaime 2012-06-14 21:52
    KattMan:
    cdosrun:
    KattMan:
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.

    Another possible way of getting them is through some service call, or maybe not getting them at all, let the service call access the data instead of the Asp.net application. Of course then you have the config file for the service that needs to be cleaned, but that is easier to point to a resource that has encrypted data instead of that resource being accessable from your web server.


    Or you can encrypt the data in your web.config file.

    Yes you could, but try managing that from an global perspective, any time a password changes (remember PCI requires this) you need to update all the web configs you have in your system.

    Or you could have one file that has this that all the web.configs point to and simply change that one file.

    Granted, if your company is small enough to only have one site or service then this isn't a problem.
    Decrypting, changing, and re-encrypting is easy to script:

    Aspnet_regiis -pdf "connectionStrings"
    <<change password>>
    Aspnet_regiis -pef "connectionStrings"

    Also, creating a parent web.config that multiple applications inherit from is a built-in feature of ASP.Net, so you don't have to write customer code to create a pointer to a single configuration. The code is entirely unaware of the inheritance.
  • I ar the frist! 2012-06-14 23:34
    PCI compliance? Who the hell care about that?!
  • Dirk 2012-06-14 23:48
    Where's the WTF? They are simply making a mechanism to point at different dbs by config. The enterprise library does something similar by it's default connection string mechanism.
    Sure, they should have had a named key for the default connection string key, however, not a huge issue.
  • Dirk 2012-06-14 23:53
    Dirk:
    Where's the WTF? They are simply making a mechanism to point at different dbs by config. The enterprise library does something similar by it's default connection string mechanism.
    Sure, they should have had a named key for the default connection string key, however, not a huge issue.

    Ummm, ignore this comment. Not enough coffee yet or I'm still high.
  • emurphy 2012-06-15 03:12
    anony-mouse:
    Haven't heard of Windows Authentication, eh?
    If you're using ASP.NET you're probably using MS SQL Server, in which the proper security model is to use Windows auth instead of a hard coded login/password.


    Unless the web site is meant to be accessed from outside your network.
  • JimLahey 2012-06-15 03:44
    Too many people don't know that .net lets you encrypt connection strings, besides which, your IIS should be configured in such a way that httprequests to web.config are denied by default.

    Does anyone else take issue with the way the data access layer is called "DAL"? shit like that makes my blood boil, like calling your business layer "BLL" - what does that class do again? oh yeah, it logics your business layer, how silly of me.
  • Dave 2012-06-15 04:37
    I ar the frist!:
    PCI compliance? Who the hell care about that?!


    Well, since PCI compliance unambiguously guarantees impenetrable security, you simply implement PCI, then you don't need to think about security and best practices any more. It's a huge saving, and a great deal of peace of mind, for any company.

    The more you know.
  • AB 2012-06-15 05:10
    KattMan:
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.

    Another possible way of getting them is through some service call, or maybe not getting them at all, let the service call access the data instead of the Asp.net application. Of course then you have the config file for the service that needs to be cleaned, but that is easier to point to a resource that has encrypted data instead of that resource being accessable from your web server.


    TRWTF. Idiots like you are what lead to code like the OP.
  • Hewes 2012-06-15 06:54
    Dave:
    I ar the frist!:
    PCI compliance? Who the hell care about that?!


    Well, since PCI compliance unambiguously guarantees impenetrable security, you simply implement PCI, then you don't need to think about security and best practices any more. It's a huge saving, and a great deal of peace of mind, for any company.

    The more you know.


    Wow...

    Just wow, seriously, you said this?

    PCI is more a minimum requirement for not being as holey as a leaky sieve.

    Dothing nothing but meeing the minimum requirements of PCI DSS means you qualify to call yourself more secure than than a firevault made of chocolate, nothing more.
  • Hmmmm 2012-06-15 06:57
    Dirk:
    Ummm, ignore this comment. Not enough coffee yet or I'm still high.

    Probably both if I'm any judge...
  • Hmmmm 2012-06-15 06:59
    Hewes:
    Wow...

    Just wow, seriously, you said this?

    You must be new here.

    -100 internets for falling for obvious troll...
  • Silfax 2012-06-15 07:39
    HungarianProf:
    The Real WTF is that they do not have a string variable called HitCount (or anything that begins with Hit ...)

    in Hungarian notation would that be sHitCount?
  • Jeff 2012-06-15 07:40
    Jaime:
    Jeff:
    KattMan:
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.
    But, to decrypt them, you need the key. Where do you get that? From another file? Shouldn't that be encrypted too?
    DPAPI. It's secure against everyone except administrators or those with physical access to the box. Almost nothing can help you in those two cases.
    Hey Jamie, are you a salesman? (Saleswoman?) Your answer surely makes me think so.

    1. Answer a technical question with a buzzword.

    2. Assurance that it "is secure" -- an unachievable state, but a nice marketing term.

    3. No discussion of how this magic might achieve its lofty promise.
  • Bridget 2012-06-15 08:07
    Dave:
    I ar the frist!:
    PCI compliance? Who the hell care about that?!


    Well, since PCI compliance unambiguously guarantees impenetrable security, you simply implement PCI, then you don't need to think about security and best practices any more. It's a huge saving, and a great deal of peace of mind, for any company.

    The more you know.


    We must work at the same place, because I swear I've heard that before in the past few months.
  • Todd Lewis 2012-06-15 08:17
    TRWTF is not doing this in Perl. Then nobody would expect it to be right anyway, so no disappointment.

    [I actually like Perl. It's like python for people who aren't afraid of punctuation.]
  • Nagesh 2012-06-15 08:23
    PedanticCurmudgeon:
    Nagesh:
    Um, I'm not fluent in VB.NET, but I can't see any "look it up by position" in the code snippet here. What they are doing seems to be to ask if the key at position 0 is 'ConnectionString', and then look it up by key. In all other cases -- including when 'ConnectionString' is the key in some non-zero position -- then they pretend that whatever the key at position 0 is, is the right connection string to use!

    That's much more of a WTF than doing something that works but in a unnecessarily roundabout way.
    Did someone forget to switch sock-puppet names again?

    "Sock puppet"? It's only a sock puppet if a reasonable person could think the names denotes an actual person. Effectively, "Nagesh" is just the accepted spelling variant for "Anonymous" here.
  • radarbob 2012-06-15 08:35
    Silfax:
    HungarianProf:
    The Real WTF is that they do not have a string variable called HitCount (or anything that begins with Hit ...)

    in Hungarian notation would that be sHitCount?

    +10 internets, Silfax.
  • Pedant 2012-06-15 08:42
    Willing to hazard good money that all the commented out crap was an initial effort to store all their configuration in a database, including the connection strings.

    All was going well until, hang on, seem to be getting some deep recursion here...
  • PedanticCurmudgeon 2012-06-15 08:48
    Silfax:
    HungarianProf:
    The Real WTF is that they do not have a string variable called HitCount (or anything that begins with Hit ...)

    in Hungarian notation would that be sHitCount?
    Does anyone have a "That's the joke!" image I can borrow?
  • QJo 2012-06-15 08:53
    HungarianProf:
    The Real WTF is that they do not have a string variable called HitCount (or anything that begins with Hit ...)


    Oh come on! Get the joke right. "HitList".
  • veggen 2012-06-15 08:57
    bewbs:
    second!

    .
    .
    .
    .not spam

    What do you mean by "not spam"? It so very much *is* spam.
  • ¯\(°_o)/¯ I DUNNO LOL 2012-06-15 09:23
    Hewes:
    PCI is more a minimum requirement for not being as holey as a leaky sieve.

    Dothing nothing but meeing the minimum requirements of PCI DSS means you qualify to call yourself more secure than than a firevault made of chocolate, nothing more.
    I'll have you know that my computer has FOUR of them PCI slots!
  • MikeD 2012-06-15 10:13
    You don't have to have the user name and password in the connection string. Most places I worked that required PCI compliance used a trusted connection and has the app/service run with the active directory identity of a user that was setup with access to the database.
  • Sayer 2012-06-15 10:55
    I don't know why anyone bothers to post technical rebuttals that have the chance of being shot down - when it's much easier to appear sophisticated by just bitching about the evils of hungarian notation.
  • M 2012-06-15 10:57
    Jeff:
    Jaime:
    Jeff:
    KattMan:
    Another WTF is how ASP.Net defaults breaks PCI compliance.

    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.
    But, to decrypt them, you need the key. Where do you get that? From another file? Shouldn't that be encrypted too?
    DPAPI. It's secure against everyone except administrators or those with physical access to the box. Almost nothing can help you in those two cases.
    Hey Jamie, are you a salesman? (Saleswoman?) Your answer surely makes me think so.

    1. Answer a technical question with a buzzword.

    2. Assurance that it "is secure" -- an unachievable state, but a nice marketing term.

    3. No discussion of how this magic might achieve its lofty promise.


    DPAPI isn't magic, but it is a pretty standard way of handling encryption in windows without worrying too much about key management. Wikipedia has a decent description, just look up "Data Protection API"
  • PedanticCurmudgeon 2012-06-15 11:13
    Nagesh:
    "Sock puppet"? It's only a sock puppet if a reasonable person could think the names denotes an actual person. Effectively, "Nagesh" is just the accepted spelling variant for "Anonymous" here.
    My point was that you posted as Fake Nagesh with correct spelling and grammar, and didn't use any of these words: ain't, massage, scarecrow. You also didn't post any lame pictures purporting to be from Hyderabad. That sets a bad precedent.
  • Mantorok 2012-06-15 11:16
    Pedant:
    Willing to hazard good money that all the commented out crap was an initial effort to store all their configuration in a database, including the connection strings.

    All was going well until, hang on, seem to be getting some deep recursion here...


    lol my thoughts exactly, funny how a few commented-out variables can lead to such a conclusion that is probably 99.9% accurate :-)
  • Nagesh 2012-06-15 11:35
    PedanticCurmudgeon:
    My point was that you posted as Fake Nagesh with correct spelling and grammar, and didn't use any of these words: ain't, massage, scarecrow. You also didn't post any lame pictures purporting to be from Hyderabad.

    No, that is <em>my</em> point. By publishing cogent messages (as cogent as I can make them, anyway) under the shared Nagesh moniker, I hope to dilute it enough that the "fun" will wear off and the wiseguys will stop polluting the comment threads. (Anyone reading this is hereby cordially invited to join forces).
  • Nagesh 2012-06-15 11:42
    Also, the being use of the wrong kind of marking up abeve ain't being attempt at metahumor. Just the failure of using preview frist adn the comment system ain't being allowing to massage the message post posting.
  • Meep 2012-06-15 12:44
    Todd Lewis:
    TRWTF is not doing this in Perl. Then nobody would expect it to be right anyway, so no disappointment.

    [I actually like Perl. It's like python for people who aren't afraid of punctuation.]


    Python is just like Perl for people who aren't afraid of someone reading their code.
  • Nagesh 2012-06-15 14:12
    emurphy:
    KattMan:
    Connection strings have usernames and passwords in them in plain text when usign them this way. Either encrypt them or do not use the config file to store them, have the config file point to something else that has them and that is encrypted.


    Well, you can encrypt them in the config file, so I assume "this way" refers to this (unused) part:

    sColumns = "DataLink, Platform, Login, Password, Server, Database"


    Encryption is less of a big deal if you're dealing with an intranet app, or if the login only has read access to data that you want to share with the general public anyway.


    Encryption is general painful. Best leave password in plain text on webserver.
  • Nagesh 2012-06-15 14:14
    Nagesh:
    PedanticCurmudgeon:
    Nagesh:
    Um, I'm not fluent in VB.NET, but I can't see any "look it up by position" in the code snippet here. What they are doing seems to be to ask if the key at position 0 is 'ConnectionString', and then look it up by key. In all other cases -- including when 'ConnectionString' is the key in some non-zero position -- then they pretend that whatever the key at position 0 is, is the right connection string to use!

    That's much more of a WTF than doing something that works but in a unnecessarily roundabout way.
    Did someone forget to switch sock-puppet names again?

    "Sock puppet"? It's only a sock puppet if a reasonable person could think the names denotes an actual person. Effectively, "Nagesh" is just the accepted spelling variant for "Anonymous" here.


    I am telling you not to be anonymous, but post using real name, like I am.
  • PedanticCurmudgeon 2012-06-15 14:15
    Nagesh:
    PedanticCurmudgeon:
    My point was that you posted as Fake Nagesh with correct spelling and grammar, and didn't use any of these words: ain't, massage, scarecrow. You also didn't post any lame pictures purporting to be from Hyderabad.

    No, that is <em>my</em> point. By publishing cogent messages (as cogent as I can make them, anyway) under the shared Nagesh moniker, I hope to dilute it enough that the "fun" will wear off and the wiseguys will stop polluting the comment threads. (Anyone reading this is hereby cordially invited to join forces).
    We actually tried something similar before with the "no laughing matter" jerk. It didn't work, but he seems to have gotten bored and left a few months later. Good luck. You'll need it.
  • Top Coder 2012-06-15 15:35
    Lots of the old guys were funnier than Nagesh
  • D-Coder 2012-06-15 15:49
    Top Coder:
    Lots of the old guys were funnier than Nagesh
    All of the old guys were funnier than Nagesh. Even the not-funny ones.

    Even the dead ones.
  • feugiat 2012-06-16 00:18
    DB:
    Frist frist.


    First idiot is what you are.
  • feugiat 2012-06-16 00:19
    bewbs:
    second!

    .
    .
    .
    .not spam


    Second idiot, but first dickhead.
  • feugiat 2012-06-16 00:22
    Nagesh:
    The major atrocity here is that instead of simply getting the connection string by key ('ConnectionString' in this case), they first look it up by position. This makes no sense. Later, if the lookup-by-position works, then they get it by key.

    Um, I'm not fluent in VB.NET, but I can't see any "look it up by position" in the code snippet here. What they are doing seems to be to ask if the key at position 0 is 'ConnectionString', and then look it up by key. In all other cases -- including when 'ConnectionString' is the key in some non-zero position -- then they pretend that whatever the key at position 0 is, is the right connection string to use!

    That's much more of a WTF than doing something that works but in a unnecessarily roundabout way.


    Very fluent, I see.

    The thing with [0] is what the position-lookup refers to.
  • Nagesh 2012-06-16 14:38
    feugiat:
    Nagesh:
    Um, I'm not fluent in VB.NET, but I can't see any "look it up by position" in the code snippet here. ...


    Very fluent, I see.

    The thing with [0] is what the position-lookup refers to.

    Oh, that makes sense. I somehow got into my head that a "lookup by position" would involve a loop over all possible positions checking if the key was right at one of them. Apparently I underestimated the WTFery even as I was explaining it. Sigh.
  • wbrianwhite 2012-06-16 14:40
    M:
    Chronomium:
    The worst part is probably all the variables defined at the start of the code, especially those commented out. Only two of them are actually used, while the rest imply that some sort of heavy-duty database punching was attempted at some point.


    Maybe they tried putting all the connection strings in a database table?

    Not removing the obviously useless code is definitely a WTF. Also, who the heck is still using hungarian notation? sHere, sThere, sEverywhere.


    You can put every database connection string except one in the database. Nothing wrong with that. Allows an easy UI to update the conn string that applies across your whole server farm
  • qbolec 2012-06-17 12:09
    Out of curiosity I tried to join this forum using login "Nagesh" written with Cyrylic "a", but all I've got was this cryptic error message:
    "Sign in name must start with a-z/A-Z character and cannot contain > or <."

    I believe this message has some curious implications for security model employed by this forum, in particular in terms of escaping HTML entities...
  • Nagesh'); DROP TABLE 'Articles';-- 2012-06-17 18:25
    qbolec:
    Out of curiosity I tried to join this forum using login "Nagesh" written with Cyrylic "a", but all I've got was this cryptic error message:
    "Sign in name must start with a-z/A-Z character and cannot contain > or <."

    I believe this message has some curious implications for security model employed by this forum, in particular in terms of escaping HTML entities...

    Hey, at least they're validating input. That's something.
  • ThatGuy 2012-06-17 22:58
    It's not up to the language to enforce PCI compliance. Saying it's ASP.NET's fault is like blaming a hammer for not building a house properly.

    And BTW, you can always use integrated windows authentication to connect to your DB in ASP.NET... and voila, no password.
  • Nagesh 2012-06-18 12:40
    PedanticCurmudgeon:
    Did someone forget to switch sock-puppet names again?

    I'm not him, but it seems like a good strategy to me: if we all post as "Nagesh", "Nagesh" won't stand out that much anymore)
  • Captcha:bene 2012-06-18 12:45
    Hmmmm:
    Hewes:
    Wow...

    Just wow, seriously, you said this?

    You must be new here.

    -100 internets for falling for obvious troll...

    -25 internets for misusing the word "troll".
  • Annon Too 2012-06-19 07:37
    Yes, I picked up on that as well.

    The DAL which is only get's a connection string, presumably for some other code abortion to use somewhere else is not a Data Access Layer.
  • dick 2012-06-21 07:16
    DB:
    Frist frist.

    I once knew a guy who would never stop running the same joke over and over again. He was a real looser.
  • Jasmine 2012-07-02 14:43
    Does this company name start with TMA? Cuz I think you're finding out why I quit that job :)