tabacco

+Clients
  • Content count

    30
  • Joined

  • Last visited


tabacco's Activity

  1. tabacco added a comment: IP.Board can't detect https if behind an SSL-terminating load balancer   

    Out of curiosity, what's the fix in 4.0.0?
  2. tabacco added a comment: IP.Board can't detect https if behind an SSL-terminating load balancer   

    It's less of a security vulnerability than supporting X-Forwarded-For, which is already in there. That's mitigated by adding an option to toggle it, it seems like the same could be done for trusting headers for HTTPS. Or group them into an "I'm behind a load-balancer" option.
     
    At the very least, it'd be nice if IP.Board could use one single method of determining if it's being accessed securely, rather than checking the port and the HTTPS variable in two different places.
  3. tabacco added a comment: IP.Board can't detect https if behind an SSL-terminating load balancer   

    I added a similar check to admin/sources/base/ipsRegistry.php:
    elseif ( ipsRegistry::$settings['logins_over_https'] && ( empty($_SERVER['HTTPS']) OR $_SERVER['HTTPS'] != 'on' ) && ( !isset($_SERVER['HTTP_X_FORWARDED_PROTO']) || $_SERVER['HTTP_X_FORWARDED_PROTO'] != 'https' )) { /* Bug 38301 */ ipsRegistry::getClass('output')->silentRedirect( str_replace( 'http://', 'https://', ipsRegistry::$settings['this_url'] ) ); return; } It's not exactly elegant code, but it works.
     
    FWIW, it'd be better to have a central place to check for https, rather than sprinkling checks on $_SERVER around.
  4. tabacco added a comment: IP.Board can't detect https if behind an SSL-terminating load balancer   

    Just want to point out that the same issue also causes this previously closed bug to resurface:
    http://community.invisionpower.com/resources/bugs.html/_/ip-board/force-logins-over-https-causes-admin-login-redirection-loop-r39617
     
    Except in that case it checks for $_SERVER['https'] which is likewise unreliable behind a load balancer.
  5. tabacco added a record in IP.Board   

    IP.Board can't detect https if behind an SSL-terminating load balancer
    From looking at admin/sources/classes/output/publicOutput.php:826, IP.Board only properly supports HTTPS if php reports $_SERVER['SERVER_PORT']==443.
     
    In the case of an SSL-terminating load balancer, though, this won't be the case, since the load balancer will handle the SSL and forward plain http to the backend.
     
    The usual standard in these setups is to set the following header on the request to the backend X-Forwarded-Proto: https
     
    It seems like it'd be pretty easy to hack that in on that line (and I did in my own copy):[code=:826] if ( $_SERVER['SERVER_PORT'] == SSL_PORT || ( isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) ) { $this->isHTTPS = true; return; } [/code]
    If the forum wasn't behind a load balancer, it'd be possible for a client to set the header erroneously, but I'm not sure it really matters if they do.
    • 0 replies
    • 0 views
  6. tabacco added a comment: Backspace key glitch in editor when using formatting   

    Nope. It backspaces correctly on their demo.
  7. tabacco added a comment: Backspace key glitch in editor when using formatting   

    Sorry, I should add I'm seeing the behavior in Chrome 21.0.1145.0.dev and the user who reported the problem is using Chrome 19,0.1084.46
  8. tabacco added a record in IP.Board   

    Backspace key glitch in editor when using formatting
    There's some weirdness when using formatting controls in CKEditor around the backspace key. Here's the most isolated example:
    [list=1]
    [*]Start a new post
    [*]Type some characters.
    [*]Press the 'Italic' button (or use cmd-I or ctrl-I on your keyboard)
    [*]Type some more characters
    [*]Without existing italic mode, press backspace
    [/list]
    Expected behavior: One character is deleted from the end of the string

    Actual Behavior: Cursor moves to the start of the italicized block and deletes the character immediately before it as if the italic block didn't exist.
    • 0 replies
    • 0 views
  9. tabacco added a comment: Forums with lots of emoticons experiencing weird reordering behavior   

    (The server-side code already looks for $_REQUEST['emoticons'] so only the client-side change is needed)
  10. tabacco added a record in IP.Board   

    Forums with lots of emoticons experiencing weird reordering behavior
    When using the drag-and-drop emoticon reordering, the AJAX request that's sent to the server with the new order uses GET, with the emoticon ids as query parameters. 'emoticons[]=2&emoticons[]=6', etc. The problem is, if you have lots of emoticons, this can exceed limitations on URI length, causing the array of emoticons to be truncated.

    Because the code that handles the request sets all emoticons' order to 0 then loops through the array to set them all in the right order, this can lead to the truncated emoticons all having a value of 0 in emoticons.emo_position, causing some portion of emoticons to appear in random order at the top of the list.

    There's a one-liner fix for this, though, which is to use POST to submit the data.

    [color=#282828][font=helvetica, arial, sans-serif]In admin/applications/core/skin_cp/cp_skin_emoticons.php:238[/font][/color]
    [code]
    jQ("#emoticons_table").ipsSortable('table', {
    url: "{$this->settings['base_url']}{$this->form_code_js}do=reorder&md5check={$this->registry->adminFunctions->getSecurityKey()}&id={$this->request['id']}".replace( /&/g, '&' ),
    serializeOptions: { key: 'emoticons[]' }
    } );
    [/code]

    To fix, the sendType option just needs to be passed:
    [code]
    jQ("#emoticons_table").ipsSortable('table', {
    url: "{$this->settings['base_url']}{$this->form_code_js}do=reorder&md5check={$this->registry->adminFunctions->getSecurityKey()}&id={$this->request['id']}".replace( /&/g, '&' ),
    serializeOptions: { key: 'emoticons[]' },
    sendType: 'post'
    } );
    [/code]
    • 0 replies
    • 0 views

About Me

Status Feed