Jump to content

maxxd

Gurus
  • Posts

    1,660
  • Joined

  • Last visited

  • Days Won

    52

Posts posted by maxxd

  1. 2 hours ago, SaranacLake said:

    I am pretty sure the media queries just determine which image gets displayed, but they don't have the ability to stop your web page from downloading a larger image, but maybe I'm wrong.

    I'm talking about media queries associated with the picture element, not CSS. There's more information here.

    2 hours ago, SaranacLake said:

    I also thought about offering eBooks, but I have the same fear of piracy as with PDFs.

    I've not created any eBooks myself, but doesn't it handle the DRM natively? I'm pretty sure if I buy a Barnes and Noble book on my nook I can't just transfer the file to my wife's computer and open it - I think I have to be in another nook app and logged in with the same credentials. Although I'm not actually sure I've tried that now that I type it out loud...

  2. Yes, people will read books of all types on mobile devices. My wife interacts exclusively using her iphone and ipad, and I'm currently reading a tutorial-style book on my desktop, surface, and galaxy phone depending on where I am and what I have on me at the time (and just to give some frame of reference, we're both older than you are so it's not just GenZ and Millennials).

    As far as javascripting goes, there are many drop-in libraries that only need the user to modify the image attributes in order to add lazyloading to the page - this one, for instance. And even then, you can use the picture element and media queries to display completely different images to different screen sizes (and to a degree devices, if you hack the media queries enough).

    Really, what you're concerned about isn't newfangled technology or practices, it's modern HTML. Assuming, of course, that you're building your website from scratch - if you're using a CMS it might be a bit more difficult. I know that trying to use the picture element inside a WordPress post is (or was about a year ago, anyway) damned near impossible.

    This is a completely unrelated thought and I'm not even through my first cup of coffee so please excuse it, but have you considered just offering downloadable PDFs of your tutorials? That way people know what they're in for before they click the link and you save yourself all this work - there's no need to worry about layloading and mobile performance and whatnot.

  3. It sounds like you're saying that the DB connection is in the include file, but you'd like to not include the include file if the DB connection in the include file fails?

    You can't not include a file after you've included it, and you'll have to include it to see if the connection is successful. What's the actual issue you're dealing with?

  4. 1 hour ago, SaranacLake said:

    So if user went to an e-commerce site that just submitted the product_price to the server and had no validation (e.g. <> 0), then he/she could get a hell of a deal on something, right?

    Yes, and that's what we've been saying since the beginning - don't pass the price from the form. Pass the product ID and use that to look up the price.

    4 hours ago, kicken said:

    Firefox has an Edit and Resend button you can use to craft a new request.  This just sends the request and shows the response in the dev tools, it won't cause the page to change or trigger and result processing in javascript.

    Not gonna lie, I did not know that - thanks for the heads-up!

  5. 7 hours ago, SaranacLake said:

    Because if a field is "hidden" you wouldn't be able to see it on the actual form.

    You can see and alter any of the page's html in the inspector tab of your developer tools.

    7 hours ago, SaranacLake said:

    Is there a way to make it so they cannot discover things like the "product_id" in a hidden field?

    No.

  6. Yes, every field has to have a name attribute for PHP to recognize it. So, yeah - it's a good point, depending on how you're pages are set up you'll probably want a hidden field to pass the product ID. My point was mostly don't pass the price for the product and assume that it hasn't been modified by the user. Which leads us to the next question:

    26 minutes ago, SaranacLake said:

    Can you explain a little more how they would do that if I had a hidden "Price" field?

    Sure - put this on your local dev environment:

    <?php
    if(!empty($_POST)){
    	print("<p>{$_POST['hidden_field']}</p>");
    }else{
    	print("<p>not set</p>");
    }
    ?>
    <!DOCTYPE html>
    <html lang="en">
    <head>
    	<meta charset="UTF-8">
    	<meta name="viewport" content="width=device-width, initial-scale=1.0">
    	<title>Document</title>
    </head>
    <body>
    	<form method="post">
    		<input type="hidden" name="hidden_field" value="originally set!" />
    		<input type="submit" />
    	</form>
    </body>
    </html>

    Load the script into your browser and click the submit button; see where 'not set' changes to 'originally set!'? Groovy - now, open your developer tools from the browser and select the field with the 'hidden_field' name attribute and change the value attribute on that field to 'hacked, yo!'. Now click the submit button again. Without any sort of validation or server-side checking, the form happily passes 'hacked, yo!' to the processing script, and if that script processed a product price the user could easily change it to 0.00 or less.

    *edit* If they mess with the product ID.... well, honestly who cares? They'll just end up paying the correct price and getting a different product. It doesn't really help them out at all.

    • Like 1
  7. Pass a product ID and quantity to the order form, then get the product price from the database and calculate the total price at that point. These fields should both be visible to the user. You can use a hidden honeypot or nonce field if you really want to, but if you're charging money I'm not sure many bots would actually pay for something at random (though I could be wrong so don't quote me on that).

    The only time you should deal with the price on the server-side (other than for output purposes) is when the order is being completed - you need to make sure the user doesn't use the developer tools to change the price during the sale, but once the sale is made you need to track how much the product cost at the time of the purchase in case the price changes in the future (which it will).

    • Like 1
  8. Part of the reason jQuery became what it is is because of cross-browser compliance. You didn't have to do the `if(ie), else(everyone_else)` jig. However, as requinix pointed out, these days an AJAX call is pretty much an AJAX call regardless what browser you're using, assuming it's not an obsolete browser. Shoot, even fetch() is supported by everything except ie11, and I'm pretty sure there's a polyfill for that.

  9. 21 minutes ago, gizmola said:

    have decided not to try and upgrade them to Catalina, as I read that it broke a bunch of 16bit apps, and I don't want to spend time or money trying to upgrade things that currently work fine for me

    I remember we had issues with the Mojave > Catalina upgrade on our iMacs at my last job.

  10. I've seen some articles where they pass `idekey` and `remote_host` via the arguments parameter, but that doesn't seem to make a difference here. I also tried passing the path to the specific script that I'm trying to test - again, AFAIR that didn't make a difference. `cwd` is actually set in my launch file, and again I don't recall `externalConsole` having any affect. The others I didn't know about - thanks for the pointers, I'll do some digging.

    The thing I find most annoying is that every tutorial or set up or walk-through I find seems to use a different subset of the launch settings - the only consistent one I've found is `remote_connect_back` should be set to 0 or it won't work. Admittedly, it's probably a setting somewhere else in the system; I'm afraid I may just have to nuke it from space and start over.

  11. Hi y'all.

    I've been scrubbing Google for this and from everything I'm reading and seeing, this should be working - problem is it's not... Here's the deal. I've got a docker image spun up with my development environment and all that's fine. I've updated the php.ini on the image with the following:

    [xdebug]
    xdebug.remote_autostart=1
    xdebug.remote_enable=1
    xdebug.remote_log="/var/log/xdebug.log"
    xdebug.remote_host=host.docker.internal
    xdebug.remote_handler=dbgp
    xdebug.remote_port=9000
    xdebug.remote_connect_back=0
    xdebug.collect_vars=1
    xdebug.collect_returns=1
    xdebug.collect_assignments=1
    xdebug.profiler_enable=1
    xdebug.idekey=VSCODE

    I created a new config in launch.json as so:

    {
      "name": "Remote XDebug",
      "type": "php",
      "request": "launch",
      "port": 9900,
      "pathMappings": {
        "/var/www/html" : "${workspaceRoot}/myDir"
      },
      "cwd": "${workspaceRoot}/myDir"
    }

    I set a few breakpoints in VSCode in my file on the host system, start the debugger, and docker-compose run into the image, where I `php test.php` and expect to be brought into the debug session as I would on the host system (that part works). However, it doesn't happen - I never get into the debug session on the host system. My xdebug.log does, however, look like everything should be working:

    [11] Log opened at 2020-05-04 20:37:03
    [11] I: Connecting to configured address/port: host.docker.internal:9000.
    [11] I: Connected to client. :-)
    [11] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/html/testing/test.php" language="PHP" xdebug:language_version="7.1.33" protocol_version="1.0" appid="11" idekey="VSCODE"><engine version="2.9.1"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2020 by Derick Rethans]]></copyright></init>
    [11] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" status="stopping" reason="ok"></response>
    [11] Log closed at 2020-05-04 20:37:03

    Oh, and my docker-compose file maps port 9900 on the host to 9000 image.

    service:
      build:
      context: '.'
      volumes:
        - ../myDir/:/var/www/html/
        - ../logs/:/var/log/
      ports:
        - 80:80
        - 443:443
        - 9900:9000
      networks:
        - test
      environment:
        - ENVIRONMENT=development
      depends_on:
        - database
    

    Anybody have any ideas? I'm just burning time on this now, but I'd very much like to be able to debug in the docker container because I'm currently working with a couple different companies that use wildly different php/server setups and I don't want to have to try and keep that straight or have to continually nuke my machine.

    Thanks in advance!

  12. Caveat to keep in mind, though - any time/date data you've inserted into a database is now technically incorrect as it was inserted using the server's timezone. If you have any queries that pull data by date/time, that may become a factor - daylight savings and whatnot can sometimes cause returns to be a full day off, depending on how the query is built and how the data was stored.

    Of course, that could just be the lingering PTSD from the several months long timezone-based project I just finished at work...

  13. What's the fault code and string it should output on failure? The docs state that SoapClient::__construct() will throw a SoapFault exception if the WSDL URI can't be loaded - it doesn't look like your endpoint is WSDL.

  14. If you're trying to comment on an existing comment, you need a parent_id column in your table. The id of the initial comment would then go into that column.

    For a more robust and future-proof solution, you'd create a separate table to track the parent/child relationships between comments, but the idea is the same.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.