Jump to content

tibberous

Members
  • Posts

    1,187
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by tibberous

  1. My guess would be that it keeps you from screwing up the headers, which can get you marked with some servers.

     

    Spam filtering varies a ton from company to company - my emails get through in gmail, marked as spam in yahoo. Gmail seems to put a lot of weight into marking emails as 'Not Spam', gmail is also accurate as hell.

     

     

  2. Depends on who you are looking at to hire you - a lot of companies ask for a bachelors to try and filter the canidates, but a lot will also wave it if you can give them a reason too. After a couple months of only getting shit offers, my friend actually got a job by sending out a 1 sheet, large print letter that said, "Take a look at xxxxxx.com! You can hire the guy that made it! Call me at XXXXXXXXXXX!"

     

    Granted, that won't work everytime, but it doesn't have too - That approach also works good if you can talk as good at you can program :)

     

    In general, if you spend as much time looking for a job as you do getting a bachelors, you'll have a job a lot faster and for a hell of a lot less money than someone who goes to school for four years. The problem is that people send out 10 resumes, don't get a job, and give up.

  3. I guess it would depend a lot on what their doing. If you could give them something defined to work on, like:

     

    Make a function that takes in text, strips out all the tags but bold, an returns the length.

     

    Then they don't really need to know how everything else works. I'd try to find chunks like that, not small enough to be considered busy work, but small enough that your not overwhelming somone who might already be nervous to be there.

  4. How much stuff do you stick on one line?

     

    I generally do something like this:

     

    if(!$id = intval($_REQUEST['id']))
    return "No id was sent.";
    

     

    But won't do something like:

     

    mysql_query("select * from users where name='".mysql_real_escape_string(trim($_REQUEST['name']))."'");
    

     

    I hate when people use too many, or not enough, lol.

  5. ...It may mean more sales...

     

    That's why.

     

    And because being able to only run payments through PayPal seems amateur, and because linkpoint will run a credit card transaction at 1.85%, which a LOT less than paypal.

     

    Down the road we might add paypal and google checkout, but linkpoint seems to be the cheapest way and simplest way to process payments.

  6. Stephen's right, you can get a script to run 24/7, I made an uploader one time that ran 23.5 hours a day, and only restarted itself with cron to release it's memory and fix if it crashed - and it never crashed. All cron is is a program that runs all the time, there isn't much difference between it and having PHP do it.

     

    I would start it with putty and background the process though - we have to do some weird stuff to keep it from dieing when the session was closed.

  7. We need to keep them on file so users can get billed without retyping them. If they have to reenter their card number every time, the'll buy less stuff. While we use the last four digits for display purposes, we can't run a 4 digit card number through linkpoint.

     

    And the way I set it up, I was thinking it would be pretty much impossible to get mysql access to the card database without ftp access, but it still might be worth encrypting them for the few extra minutes it would take. At least then if I need to make backups of the database, I can do so without having to then encrypt them.

     

    I don't think I can use an SSL cert, since we already have one for a different subdomain on the server. Unless their is a way to install two that I don't know about, because the price of an unlimited sub-domain cert is insane. I will look to see if there is a way to run two certificates on the same server - I was even thinking about getting a free cert from that one free cert company that only works with Firefox, and then using it if they were using Firefox, and otherwise just switching to the non-SSL version.

  8. I am building a system that needs to store credit cards, and am trying to make sure they are safe. Here i what I did so far:

     

    1) Turned off all the other websites. It was already a dedicated, but I didn't want it to get hit through another site we had.

    2) Put the actual numbers in a separate database. All this database does is hold the real number, all the other info is in a regular database. For this new database, I made a new user account - it is the only one that can access it, and only them with select, update and inserts.

    3) Made it so that only a few, command line scripts can touch the credit card numbers. These scripts are outside the restricted basedir, so if someone could do a "../../../../../creditCards\0crap.jpg" anywhere in my code, they can't now.

     

    Is their more I should do? I thought about encrypting the numbers, but it seems like if they have enough access to my system to get the encrypted passwords, they'd have enough access to just go get the file the decrypts them. I don't want to use ioncube - but it's been suggested, again though, at that point your more talking about how to stop people with full ftp access to the system.

  9. If mysql_fetch_assoc is false, mysql_num_rows is false, it's stupid to explicitly check. It's also not at all relevant to the question, nor is rewriting my code with error handling.

     

    I'm using navicat, it displays the correct value, but I am pretty sure that is because it is fixing it. It is return the field name for all the rows.

     

    I think it might be like an html checkbox, where it's value is always the same, but it's checked property changes.

     

    And I looked at the doc's. It says I can get the index by refering to the field in 'interger context', but I'm not sure how to do that, and I'd really rather have the value as text.

×
×
  • 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.