This is the third day of my participation in the August More Text Challenge

People want to move up as water has to flow down.

demand

Recently, the leader saw a thing that seemed to be able to install force, so he posted a screenshot in the group, and then wanted us to make a same thing, the effect is as follows:

When the user clicks on F12, there’s a breakpoint on the page, and then it goes blank, and that’s it, right?

Train of thought

  • Here you can see at a glance, is to use the debugger to complete, as for how to use the debugger to complete? Just write it in code, right? How do you know if the user is in debug mode? Will writing the debugger directly into the code cause our webpage to not work properly?
  • Sometimes thinking too much is overthinking, programming needs more practice, practice leads to truth. As long as the debug mode is not turned on, the code will not execute the debugger operation. As long as I press F2 code to run the debugger, it will be suspended, and then I can see the contents of the debugger nearby
  • But how can we tell if the user is in debug mode? At first, I just wanted to execute the code when the window size changes to implement breakpoints, but is that reasonable? When the user clicks on the breakpoint next, the user may skip the current debugger and lose the blocking effect you want. Or the user may open the debug mode to refresh the page can not listen to the window changes, so there needs to be a timer, specifically used to loop to listen whether the debugger.
  • Why do we use timers to make debuggers? The main reason is that we do not know when to open debugging, and can prevent the user from clicking bebugger. After jumping, it is invalid to intercept. Using timer is a better way to intercept at present.
  • So now that we have debug on how do we hide the contents of the page? We can use the timestamp to determine this, because the debugger suspends the code execution every time. We only need a new timestamp before and after the debugger. If the difference between the two is greater than 50, the debugger is ready. To control the page to hide what you want or show what you want.

Code tutorial

!function() {
  var timelimit = 50;
  setInterval(function() {
    var starttime = new Date(a);debugger ;if (new Date() - starttime > timelimit) {
      window.stop();
      $("#app_open_hiden").hide();
      $("#error").show();
      $("#error").html("\u7cfb\u7edf\u68c0\u6d4b\u975e\u6cd5\u8c03\u8bd5\u002c\u8bf7\u5237\u65b0\u91cd\u8bd5\u0021")}else{$("#app_open_hiden").show();
      $("#error").hide(); }},500)
}();
Copy the code

Matters needing attention

  • Do not write the debugger code in your business logic, otherwise it is easy to find your code logic near the debugger
  • The debugger code can encrypt itself, obfuscate, etc., and become complex or difficult to read
  • In fact, using the browser window size and page window size comparison page is to do whether to open the debug mode, but the debug mode and browser separate open can not listen
  • There is also an NPM package written by someone on the line that listens to whether the user is in debug mode: devTools-detect

Break the debugger

In fact, people who know how to play debugger know, how to let the debugger has not passed the hand, that is, click on a symbol to ban the debugger, the whole page does not appear debugger, click the arrow blue refresh the page can no debugger, as shown below