KT Walrus

+Clients
  • Content count

    959
  • Joined

  • Last visited


2 Followers



About KT Walrus

  • Rank
    Spam Happy
  • Birthday 11/11/2014

KT Walrus's Activity

  1. KT Walrus added a comment [4.0.6.1] Database Attachment Storage doesn't work for large originials   

    IPS Support refused to look into this problem unless I provide a web-accessible install. So, I guess this bug report will have to wait until it gets the attention of a dev here. I really just want to know whether this problem is specific to my environment or a general IPS4 bug. I can debug the problem myself, if IPS is unable to reproduce.
  2. KT Walrus added a comment [4.0.6.1] Database Attachment Storage doesn't work for large originials   

    I got a response to my ticket requesting access to my install. Since I am running locally on my Mac, my test installation is not web accessible.
    So, I provided the following additional info in the ticket in hopes that you will confirm that you are unable to reproduce this problem in your environment.
  3. KT Walrus added a comment [4.0.6.1] Database Attachment Storage doesn't work for large originials   

    I need to get this working soon, so I opened a ticket on this: 919717
    Just need to know whether this is a real bug or a config problem on my side...
  4. KT Walrus added a comment [4.0.6.1] Wrong variable used to crop square thumbnails   

    Sorry. I completely missed the '$'...
  5. KT Walrus added a comment [4.0.6.1] Wrong variable used to crop square thumbnails   

    How can this be right?
    You compute $cropProperty and then use $image->$cropProperty.
    Maybe the local $cropProperty is not used and should be removed? Maybe I am just not seeing how this is supposed to work.
  6. KT Walrus added a bug in Bug Tracker   

    [4.0.6.1] Database Attachment Storage doesn't work for large originials
    I'm not sure if this is a configuration problem or a bug in IPS4, but when I change the Storage Method for Attachments to Database, the row in the core_files table has NULL for contents column.
    I am testing this Storage Method by uploading a 7MB photo as an attachment. The upload works fine for File System Storage Method, but with Database Storage Method, it always results in NULL for the original (the smaller thumbnail version is properly saved in the Database). I have increased the mysqld variable max_allowed_packet to 16M so I think the DB should be capable of inserting a large file into the database. And, phpmyadmin (a PHP app) can insert the same file into core_files with no problem. I have increased memory_limit for PHP to 512M so memory should not be a problem. Finally, it works to upload to File System, but when I change to Database and the existing large File System files are copied to the Database, the contents column is NULL. So, this problem is not related to generating the thumbnail in the same PHP page load as the Database Insert. 
    I also checked all the log files on the server and there isn't anything unexpected appearing in the logs when the large attachment is inserted into the database. Also, smaller attachments (including the thumbnail for a large attachment) work fine, so I'm thinking maybe I am missing some configuration setting to make this work, but I can't figure out what that might be.
    Does uploading large photos (over 7MBs) to the Database work for you?
    Note: I haven't upgraded to 4.0.7 yet and am using 4.0.6.1 for this testing.
    • 3 replies
    • 89 views
  7. KT Walrus added a bug in Bug Tracker   

    [4.0.6.1] Wrong variable used to crop square thumbnails
    I noticed the parameter passed to the crop function for making square thumbnails looks wrong.
    In File.php:
    public function thumbnail( $storageExtension, $maxWidth=NULL, $maxHeight=NULL, $cropToSquare=FALSE ) { /* Work out size */ $defaultSize = explode( 'x', \IPS\THUMBNAIL_SIZE ); $maxWidth = $maxWidth ?: $defaultSize[0]; $maxHeight = $maxHeight ?: $defaultSize[1]; /* Create an \IPS\Image object */ $image = \IPS\Image::create( $this->contents() ); /* Crop it */ if ( $cropToSquare and $image->width != $image->height ) { $cropProperty = ( $image->width > $image->height ) ? 'height' : 'width'; $image->crop( $image->$cropProperty, $image->$cropProperty ); }  
    • 6 replies
    • 101 views
  8. KT Walrus added a comment [4.0.6.1] License key check failure with https install   

    ​I don't mean to be a nag, but could someone please fix these HTTPS issues before the next release?
    Also, this report was closed because the plugin developer apparently used the wrong API to do what he needed. Still, the report did expose a bug in Sockets.php that should be fixed.
    This code in Sockets.php should test 'scheme' the same way in both tests so you don't get an 'ssl://' to port 80 if the URL is PROTOCOL_RELATIVE. 
    $resource = @\fsockopen( ( $this->url->data['scheme'] === 'https' ? 'ssl://' : '' ) . $this->url->data['host'], isset( $this->url->data['port'] ) ? $this->url->data['port'] : ( $this->url->data['scheme'] === 'http' ? 80 : 443 ), $errno, $errstr, $this->timeout ); Please fix all these problems so I don't have to edit the IPS4 update files myself. The fixes are one-liners and very simple, but since I'm still developing my site, I do a clean install with each IPS4 release and I have to remember to edit the affected files or I will run into these bugs during my testing.
    Thanks.
  9. KT Walrus added a comment [4.0.6.1] Problem with IPS\Http\Request and HTTPS   

    Regardless of whether the developer was incorrect in retrieving the Theme Resource on the server side, Sockets.php should be fixed.
    At a minimum, the test on SCHEME should handle PROTOCOL_RELATIVE URLs. As I posted above, at least the two tests of the 
    $this->url->data['scheme']should test for 'https' in both cases so you don't end up with an insecure request going to port 443.
    And, since the Database Storage method returns PROTOCOL_RELATIVE URLs, this would be a problem if the plugin were to try to open a socket on the server side to retrieve some file (not necessarily a Theme Resource since all my Files are stored in the Database). Am I misunderstanding? Are you saying that it is not a bug that Sockets.php doesn't handle opening sockets for PROTOCOL_RELATIVE URLs?
    Seems like a bazaar limitation in Sockets.php.
    I would prefer that you "fixed" this limitation by handling PROTOCOL_RELATIVE URLs regardless of whether the caller is right or wrong to open a socket with such a URL. And, it would be really good if the admin could override the choice of either https or http for such calls.
  10. KT Walrus added a comment [4.0.6.1] Problem with IPS\Http\Request and HTTPS   

    Thinking about this a bit more, I think Sockets.php should have two settings for PROTOCOL_RELATIVE URLs:
    Default_SchemeDefault_PortThese settings should default to the Scheme and Port of the base_url as provided in the conf_global.php file. An admin should be able to specify these two settings in the constants.php file if they differ from the external base_url values (as is my case with a front-end HTTPS reverse proxy to the backend HTTP server).
    Then, for the socket open call, the URL should be checked for no scheme or no port on a PROTOCOL_RELATIVE URL and use the default configured values. Otherwise, the specified Scheme will be used and either the specified port in the URL or a default based on the Scheme.
    I think this would completely resolve this issue.
  11. KT Walrus added a bug in Bug Tracker   

    [4.0.6.1] Problem with IPS\Http\Request and HTTPS
    I'm testing the Emojis plugin by @sijad and have run into a problem that looks like a bug in IPS4. 
    Problem code is in system/Http/Request/Sockets.php:
    $resource = @\fsockopen( ( $this->url->data['scheme'] === 'https' ? 'ssl://' : '' ) . $this->url->data['host'], isset( $this->url->data['port'] ) ? $this->url->data['port'] : ( $this->url->data['scheme'] === 'http' ? 80 : 443 ), $errno, $errstr, $this->timeout ); Note that the Emojis plugin contains an HTTP Request, coded as:
    $set = \IPS\Http\Url::external( \IPS\Theme::i()->resource('plugins/' . $values['sod_emoji_packs'] . '.json', 'core', 'global') )->request()->get()->decodeJson(); This worked fine when I had the 'Theme Resources' stored in the File System. But, when I changed the Storage Method for the 'Theme Resources' to 'Database', the URL for this HTTP Request is turned into a URL without a 'scheme'/'protocol' (i.e., '//mysite.com/
    applications/core/interface/file/index.php?file='). The Sockets.php code does a plain text request on port 443 (which causes an error HTTP Response from my NGINX server).
    I think, at the very least, the tests on 'scheme' in Sockets.php should be consistent. That is, I suggest you change the code to:
    $resource = @\fsockopen( ( $this->url->data['scheme'] === 'https' ? 'ssl://' : '' ) . $this->url->data['host'], isset( $this->url->data['port'] ) ? $this->url->data['port'] : ( $this->url->data['scheme'] === 'https' ? 443 : 80 ), $errno, $errstr, $this->timeout ); So, the socket only does the ssl://mysite.com:443 or mysite.com:80. As it is now, the socket path is 'mysite.com:443' because the 'scheme' of the URL is not set.
    A second bug in there might be that the 'scheme' should not be empty when the Storage Method is 'Database' for the 'Theme Resources'. This works in a Browser since the URL defaults to the scheme of the page, but it doesn't work in opening a socket in the PHP code.
    I see that the code in system/File/Database.php is:
    public function baseUrl() { return (string) \IPS\Http\Url::internal( "applications/core/interface/file/index.php?file=", 'none', NULL, array(), \IPS\Http\Url::PROTOCOL_RELATIVE ); }So, the 'Database' Storage Method is generating URLs that don't have the 'scheme' set. Maybe this is okay, but I think this might cause problems for servers where only HTTPS:443 is serving PHP code and HTTP:80 is not open or is a redirect to HTTPS:443. The Socket code may handle a redirect on port 80, so this might only be a problem if HTTP:80 is not open for connections at all.
    • 4 replies
    • 151 views
  12. KT Walrus added a comment [4.0.6.1] License key check failure with https install   

    I see the cause of the missing 'https' prefix is in the check that applications/core/modules/setup/install/license.php does. My VM is running behind a reverse proxy that sets:
    _SERVER["HTTP_HOST"]ips4.ktwalrus.com_SERVER["HTTP_X_REAL_IP"]98.169.188.37_SERVER["HTTP_X_FORWARDED_SSL"]on_SERVER["HTTP_X_FORWARDED_FOR"]98.169.188.37_SERVER["HTTP_X_FORWARDED_PROTO"]httpsand not $_SERVER["HTTPS"] as the script checks for it. I could force my nginx.conf to set  $_SERVER["HTTPS"], I suppose, but this doesn't seem right to me.
    I see that:
    system/Request/Request.phpdeclares an isSecure() function that does check the various possible secure PHP server variables, so I think the license.php code should call \IPS\Request::i()->isSecure() instead of hard-coding testing only one variable.
    Of course, I still don't think the schema/protocol should be involved in the actual check, but the form action should still use the correct URL for the site.
    Also, I did a quick grep and see that these files check $_SERVER['HTTPS'] and not the other possible variables.
    system/3rd_party/tcpdf/tcpdf_autoconfig.php admin/convertutf8/system/Request/Request.phpThese files should be fixed as well.
    Also, I see several calls to \IPS\Settings::i()->logins_over_https sprinkled throughout the code. I think this setting should be changed to TRUE if \IPS\Request::i()->isSecure() returns TRUE for the current page load (regardless of what the setting is in the ACP).
    Hopefully, you can scrub the code once more to make sure that HTTPS is detected and used correctly everywhere in the source, once and for all.
     
  13. KT Walrus added a bug in Bug Tracker   

    [4.0.6.1] License key check failure with https install
    I just did a fresh install of 4.0.6.1 for the domain https://ips4.ktwalrus.com and the form to submit the license key on install was using the insecure http://ips4.ktwalrus.com and refused to accept the submit complaining that there was another site using my license key.
    Luckily, I had a spare inactive license key and registered with that.
    I think there are two bugs here:
    The form should use the secure url.The license key check should not consider the schema in determining whether the key is acceptable. That is, IPS should only store '//ips4.ktwalrus.com' as the site url and not the 'http:' part and only check on the 'domain name/uri'. It is possible that this is already working as designed since I think I have http redirected to https so it should have worked. It could be some other bug that prevented me from spinning up a new VM and installing the new 4.0.6.1 on it, but in the Purchases page, it clearly shows http is in the URL associated with the key. So, I now have 2 licenses with one showing https://ips4.ktwalrus.com ​and the other showing http://ips4.ktwalrus.com.I am still trying to develop my site, but in the end, my custom apps will all be on subdomains to the real site. For example, if the real site uses https://ktwalrus.com, my custom apps will run on https://app1.ktwalrus.com and https://app2.ktwalrus.com. I'm hoping that the license key check will allow custom apps to run on different subdomains without complaint to the admin user. If you fix #2 above, hopefully, you can test and make sure that custom apps on subdomains work fine too. I'm sure I am not the only customer putting custom apps on subdomains, so this probably already works, but I thought I'd mention it so I won't have to open a bug report on this later (if it is a problem).
    • 3 replies
    • 130 views
  14. KT Walrus added a bug in Bug Tracker   

    [4.0.2] AdminCP links to http not https
    I'm not sure if this is a problem with my simple NGINX setup (I am proxying https to an http dockerized nginx container) or a bug in IPS4, but I noticed that when I am signed in as the admin, the AdminCP link in the user nav menu redirects me to http://example.com:443/admin and not https://example.com/admin (which is the real link).
    So, NGINX gives this response:

    Note that I enabled "Rewrite URLs?" for Friendly URLs so it may be that the url is being rewritten with the http: prefix and port=443 due to that setting. 
    • 1 reply
    • 79 views
  15. KT Walrus added a bug in Bug Tracker   

    New Content Forum Filters Empty On This Site
    Not sure if this is unique to me, but I just noticed that the "Filter results by Forums" select list is empty for me in the New Content page here.

    • 2 replies
    • 110 views