Log out - or crash the site?



  •  Found in live production code this morning:

     

          Public Sub LogOut()
                LogOut()
            End Sub

     

    No wonder the application pool was crashing.



  • It's a roach motel!



  • The software doesn't want the user to logout. It's too attached to him.


    Or a way to save connexion to the database : since the user can't logout, he will login, so you save all that time processing to check for the username and password. Bonus : no need to remember the password, only need ti enter it one time !



  • @Om3rta said:

          Public Sub LogOut()
                LogOut()
            End Sub



  •  You can LogOut any time you want - but you can never leave!



  • @Om3rta said:

    Public Sub LogOut()
        LogOut()
    End Sub


    Recursion: see Recursion …



  • @Cad Delworth said:

    Recursion: see Recursion …
     

    I think that's iteration, because the semantics of "see X" break you out of the lemma>definition hierarchy.

     



  • @dhromed said:

    @Cad Delworth said:

    Recursion: see Recursion …
     

    I think that's iteration, because the semantics of "see X" break you out of the lemma>definition hierarchy.

    That doesn't make it iteration.

    BTW: http://en.wikipedia.org/wiki/Recursion_(computer_science)#Recursion_versus_iteration



  • @dhromed said:

    @Cad Delworth said:

    Recursion: see Recursion …
     

    I think that's iteration, because the semantics of "see X" break you out of the lemma>definition hierarchy.

     


    No it isn't, If the adbove link didn't make it clear code definitly will

    definition of recursion: see recursion


    [code]

    defineRecursion(){

    return defineRecursion();

    }
    [/code]



  • @b-redeker said:

    @Om3rta said:

          Public Sub LogOut()
                LogOut()
            End Sub


  • Discourse touched me in a no-no place


  • Winner of the 2016 Presidential Election

    Am I the only one that thinks it's stupid that a stack overflow will crash the whole application pool?

    Why can't the runtime determine that it's running out of room on the stack and throw an exception instead?

    I've seen recursive algorithms that with certain specific (possibly malicious) inputs will bring down several websites on a server at a time.

    @TFM said:

    In prior versions of the .NET Framework, your application could catch a StackOverflowException object (for example, to recover from unbounded recursion). However, that practice is currently discouraged because significant additional code is required to reliably catch a stack overflow exception and continue program execution.

    Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default. Consequently, users are advised to write their code to detect and prevent a stack overflow. For example, if your application depends on recursion, use a counter or a state condition to terminate the recursive loop. Note that an application that hosts the common language runtime (CLR) can specify that the CLR unload the application domain where the stack overflow exception occurs and let the corresponding process continue.



  • @joe.edwards said:

    Am I the only one that thinks it's stupid that a stack overflow will crash the whole application pool?

    Why can't the runtime determine that it's running out of room on the stack and throw an exception instead?

    I've seen recursive algorithms that with certain specific (possibly malicious) inputs will bring down several websites on a server at a time.

    @TFM said:

    In prior versions of the .NET Framework, your application could catch a StackOverflowException object (for example, to recover from unbounded recursion). However, that practice is currently discouraged because significant additional code is required to reliably catch a stack overflow exception and continue program execution.

    Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default. Consequently, users are advised to write their code to detect and prevent a stack overflow. For example, if your application depends on recursion, use a counter or a state condition to terminate the recursive loop. Note that an application that hosts the common language runtime (CLR) can specify that the CLR unload the application domain where the stack overflow exception occurs and let the corresponding process continue.

     

    That sounds like more work than it's worth. Suppose I have a recursive algorithm to search a tree for some data. If a logic error causes infinite recursion and a stack overflow which crashes the application, how do I recover from that? Display an error message to the user that just says "Search Failed" and bail out of whatever task it's working on? If it's a native application using C++ or whatever and has pointers all over the place, how do you reliably clean up any heap object or handles created during the recursion? Or what if it's a multi-threaded application and one thread has a stack overflow? The process might be out of memory and so other threads will start experiencing errors

    IMO if a stack overflow happens then the application should be considered in an undefined state and should be killed. The amount of work it would take to reliably recover would be better spent making sure that infinite recursion doesn't happen in the first place. That said, this is all a broad generalization and there may be specific cases where you can reliably recover.


  • Winner of the 2016 Presidential Election

    OK, but supposing website A brings down websites A, B, C, D, E, F, G, H, I, J, and K when a malicious user enters in a string like <scr<scr<scr<scr<scr<scr<scr [... snip ...] ipt>ipt>ipt>ipt>ipt>ipt>ipt> to try to bypass a poorly designed HTML sanitization function for a XSS attack. Is that really the most prudent reaction to what seems like a fairly recoverable scenario?

    Note that often enough, only 10% or less of the actual code executing on said websites is first-party, the rest is compiled away in some dll, so it's not simple to patch the bug.

    (Note that with a fixed or bounded number of iterations or calls to the pattern replacement, said attacker's input will actually produce the desired <script> output, unless of course, the input is rejected outright.)



  • @joe.edwards said:

    OK, but supposing website A brings down websites A, B, C, D, E, F, G, H, I, J, and K when a malicious user enters in a string like <scr<scr<scr<scr<scr<scr<scr [... snip ...] ipt>ipt>ipt>ipt>ipt>ipt>ipt> to try to bypass a poorly designed HTML sanitization function for a XSS attack. Is that really the most prudent reaction to what seems like a fairly recoverable scenario?

    Note that often enough, only 10% or less of the actual code executing on said websites is first-party, the rest is compiled away in some dll, so it's not simple to patch the bug.

    (Note that with a fixed or bounded number of iterations or calls to the pattern replacement, said attacker's input will actually produce the desired <script> output, unless of course, the input is rejected outright.)

    That's why application pools were invented.  Simply put each application in its own pool and it won't crash the other ones.  Also, the crashed site will immediately restart, if you are using in-process state then all of the session states will be dumped.

  • Winner of the 2016 Presidential Election

    Conceded.


  • Discourse touched me in a no-no place

    @joe.edwards said:

    OK, but supposing website A brings down websites A, B, C, D, E, F, G, H, I, J, and K
    Why are they sharing an application pool? Application pools don't cost nothin' but some RTFM, ya know



  • @Weng said:

    @joe.edwards said:

    OK, but supposing website A brings down websites A, B, C, D, E, F, G, H, I, J, and K
    Why are they sharing an application pool? Application pools don't cost nothin' but some RTFM, ya know

    The client I'm currently working for deploys all related applications in the same application pool. These applications also share the same technical user id. So App1 could access data from a related App2. The project manager refuses to request a new user id because it just too much work and takes ages to get things done.

    On the mainframe side things are even worse: all users are in 1 of 2 groups and some are in both. Group 1 gives access to all stored procedures and group 2 gives access to all tables. All technical users of .NET applications are in the 'stored procedure' group and therefore can access any stored procedure they like, even the ones that create new contracts

    I already proposed to the client to let our company perform an audit on security and identiy management but they don't see any problem with this. Since all stored procedures are written by them, everything is perfectly fine and nothing can possibly go wrong in their opinion. The mainframe devs here are very reluctant to even listen to what a .NET developer has to say.

    [rant]My current project has just been delayed because of problem with mainframe jobs. We have a .NET job that hourly forwards status reports to the mainframe. Every time a status changes a new report is sent but there are some external events that also trigger the sending of a report even if the status hasn't changed. One status is that "an external has requested payment for their services". When mainframe sees that status, it will issue a payment. When a same report arrives a few hours later with the same status, it will issue a payment again... You'd say that the obvious solution is to add a flag to a DB2 table to indicate that the external party has already been paid. But not according to the mainframe guys because that would mean they have to admit their code is wrong. They want to examine all events that can trigger the sending of a duplicate report and eliminate them one by one. Sometimes I really hate mainframe devs[/rant]


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.