Child pages
  • [debugger] Ability to disable debugger permanently based on cookie
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/314fb0be8aecdfc9#

Debugger in In-Portal is only enabled, when site visitor's IP address is listed in debug.php file. However this is not enough, when developers are using shared IP (for example during Network Address Translation usage) and one or more of the developers wants to disable debug mode for him only.

Also useful, when managers and developers of company, using In-Portal share the same IP address and managers don't want to be in debug mode at all.

I see this as "Disable Permanently"/"Disable" button in debugger toolbar. Once clicked user will be asked for confirmation and once confirmed there are two options:

  • disable debugger for entire domain - useful when multiple sites are developed on same domain (for manager)
  • disabled for entire site - useful for production sites

Since we will not ask user how what the area of disabling debugger, then only one should be used.

Related Tasks

INP-559 - Getting issue details... STATUS

23 Comments

  1. This should very clever and useful.

    I would call a new button as "Turn OFF".

    DA.

  2. This will be pretty convenient!

    I'm a little confused with what this means:

    >    - disable debugger for entire domain - useful when multiple sites are
    >    developed on same domain (for manager)
    >    - disabled for entire site - useful for production sites

    > 1) Bullet point 1 - in other words, dev.intechnic.com/site - disable for

  3. Bullet point 1 - disables for dev.intechnic.com/site1 and
    dev.intechnic.com/site2, even, when only used on dev.intechnic.com/site1
    Bullet point 2 - only for current website/subfolder not others on same
    domain

  4. Ilya, is it clear now?

    Alex, I have gave it a send thought - "Disable Debugger" option will work
    for everyone I think.

    DA.

  5. Anyone else has questions?

    Let's try to finalize this quickly and convert in a new task so it's not
    lost.

    DA.

  6. "Turn off" button in debugger toolbar seems a good solution, nothing to
    setup anywhere else.

    Should you create a separate cookie called "in-portal_debug", to easily
    locate and delete it if needed?

    2010/4/18 Dmitry Andrejev <dandre...@gmail.com>

  7. Yes, Phil - it will set the cookie.

    Alex, ready for a task?

    DA.

  8. Task created:

    INP-559 - Getting issue details... STATUS


  9. Here is the patch. Ready for testing. Cookie is created with 1 year
    expiration.

  10. cool. Another question I just though about this morning, because my usual
    internet connection is lost: could it also be used to permanently activate
    debug, without any specific IP address?

    2011/7/1 Alexander Obuhovich <aik.b...@gmail.com>

  11. Then it will be security hole, since everyone who will set that cookie (that
    will be the same for all users) will be able to see debugger reports, that
    could disclose some secret information about website internals.

  12. can't this cookie hold a security key? I've also thought about browser-based
    security, but it seems harder to recognize, isn't it?

    2011/7/1 Alexander Obuhovich <aik.b...@gmail.com>

  13. Then we need to store all that keys somewhere, e.g. in new table. This
    doesn't look too good.

    Better to use dyndns service and type your dyndns host instead of ip in
    debug.php. Then we can add hostname resolving during debug.php processing.
    On Jul 1, 2011 7:32 PM, "Phil -- wbtc.fr --" <p...@wbtc.fr> wrote:

  14. Yes, I like Alex's idea with Hostname resolving option!

    DA

  15. this idea sounds very easy to implement, I like it too :)

    2011/7/1 Dmitry Andrejev <dandre...@gmail.com>

  16. Then we need to start new discussion about hostname resolve abilities in
    debug.php file.

  17. Hi guys,

    I have came across the issue with current implementation of this new
    functionality when you can Disable Debugger via Cookie setting. Basically,
    if you are running multiple websites on the same domain it will Disable the
    Debugger for all site on this domain instead of just the one I have
    specified. This is happens due to Website Path which is specified when
    Cookie is set.

    By the way, I thought I would continue this discussion so it earlier to
    find all close related things in one place.

    DA

  18. Any ideas on this?

    Alex, Phil?

    DA

  19. when you talk about multiple websites, is it Sitedomain, or separate
    installs?

    If it's different installs, I'd suggest something which is missing, at
    least to me in daily work: ability to enable/disable debugger from admin,
    and maybe let IP setup in debug.php.

    2011/12/6 Dmitry A. <dandre...@gmail.com>

  20. This enable/disable debugger is only needed when your IP is already in
    debug.php but you won't want debug mode enabled and changing debug.php
    isn't an option.
    Most usual case is when all computers in office share same IP address, used
    to access Internet. Then debug mode enabled for one IP resulting it enabled
    for all computers in office, which maybe not desired effect.

    Dmitry is talking about a case, when you have several In-Portal installs on
    same domain and each install has it subfolder, e.g.:

       - http://www.main-website.com/sub-site1/
       - http://www.main-website.com/sub-site2/
       - http://www.main-website.com/sub-site3/
       - .....

    Now we have a bug, when you disable debugger for one sub-site, then it is
    also disabled for other sub-sites as well.

  21. do you mean that 1 debug.php file interact with other sub-sites, while it"s
    not in the same system folder?

    anyway my proposal about admin setting is still good, as this could store
    an info in connected user's cookie.

    2011/12/6 Alexander Obuhovich <aik.b...@gmail.com>

  22. Nope, this is the case, when each of sub-sites have that IP listed in each
    of them, but cookie to turn off debugger is set to whole domain and not a
    specific sub-site.