Jump to content
Larry Ullman's Book Forums

abigail

Members
  • Posts

    184
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by abigail

  1. Each page can set a different title in it's own file and header file (included) always stays unchanged.
  2. The way they do it is they bring up my page "inside their website". I'm sure there is a more correct way to say it. So here is url for a secure page: https://secure23.webhostinghub.com/~advice10/donate-treatment-now.php My home page is: http://adviceofthequeen.com I have to tell my code to go to https://secure23.webhostinghub.com/~advice10/ or to adviceofthequeen.com User will probably get certifcate warning. Incidentally, webhostinghub advices not to switch between secure and not secure while using their shared certificate but I do it anyway. It works very good but it takes some careful programming and I think that's why they don't like people to do it. If you want, go to my site and see how it works from user perspective. Also, I don't let SEs such as Google "see" my secure pages. These urls would be very bad for SEO, which is one reason I don't want entire site secure.. But https://adviceofthequeen.com would be fine. Webhostinghub gives this shared SSL free and if yours is only $10 it probably is shared and not your own SSL. Probably any SSL will slow down the site. That is one reason I only use it for about 6-10 pages that access the database. I have about 150 other pages and I surely don't want those slowed down.
  3. For my site I use SSL only for pages that access the database. It takes some programming to be able to swicth between secure and not secure pages. For now I use free shared SSL from webhost but I plan to upgrade later.
  4. Does my mobile detection work? Maybe someone could test it for me, using your mobile device. I have tested it at mobiletest.me and I can see it looks good. But what I don't know is if it will detect the devices. Of course, if you see anything wrong that I didn't notice, you can tell me about that too. http://adviceofthequeen.com
  5. I suggest you should try posting at their forum. I heard that PayPal has 'Evangelists'. That's what they call them. Their job is to attract people to PayPal. If you could get one of them interested in your issue, maybe she/he would do something for you. You might sublty suggest that you might have to use Stripe instead of PayPal because you can't even test PayPal.
  6. You are using semi-colon instead of colon. Also, if you pick new host search this forum for suggestions.
  7. I also want to have different sites for desktop and mobile. But I want to detect the screen width so tablet and larger get the full website and smaller gets the moble website. But I haven't researched how to do it because I'm working on something else right now.
  8. I don't understand why unsafe to use variable for tablename. When I echo $q, php has already inserted the tablename so MySql sees the same query whether hardcoded or variable. But if this really is unsafe then can I use a php Constant for the tablename?
  9. Actually, I now have a better host. My old host only permitted 2 databases. But I didn't think of using a different database for testing because I only had such limited options at the start. I'll probably make that update.
  10. How long should me key be, for best security? My tablenames are good. The reason I do it this way is because I have separate tables for testing. Like this: if (LIVE == false) $TheTable = $tUsersTable; else $TheTable = $UsersTable; Otherwise I have to test thoroughly, both the live and test code, because one typo makes the live code wrong even though test code is good. But I really don't understand why the tablename variable is unsafe but the following $q variable is safe: $q = "UPDATE Users SET salt='$salt', pass=CONCAT($salt,'$p') WHERE id='$uid' LIMIT 1"; $r = mysqli_query ($dbc, $q) There is a secondary reason I use the tablename variable, although this I could change. Already I had to rename all my tablenames when I changed webhost. If this happens again, I just change my variables instead of editing throughout the code.
  11. I have it working now because not using bound statements. But when I echo it shows weird characters and when I look at database it is alphanum. Does it matter how long the key for hash_hmac is? Why is it so unsafe to use variables for tablenames?
  12. That's ok. I noticed it seemed you read it wrong. I will try the query without the bound parameters. I really can't think of any other reason for the problem. That very same query worked when I was using SHA1(), although I also had my database type varbinary when I should have used varchar.
  13. I'm not using SHA1() anymore. I'm using the following: $p = mysqli_real_escape_string ($dbc, hash_hmac('sha256', $pass, PKEY, true)); $q = "UPDATE $TheTable SET pass=? WHERE id=? LIMIT 1"; $stmt = mysqli_prepare($dbc, $q); mysqli_stmt_bind_param($stmt, 'bi', $p, $uid); and the database type is varbinary(128)
  14. Should I not use the bound statement here? When I use this type binary, the database is empty for password. When I used type string, it was alphanumeric. $q = "UPDATE $TheTable SET pass=? WHERE id=? LIMIT 1"; $stmt = mysqli_prepare($dbc, $q); mysqli_stmt_bind_param($stmt, 'bi', $p, $uid);
  15. I want to change from SHA1 to hash_hmac() as you suggest. I am able to update the database but not retrieve that user, i.e., I can Register but not Login. The mysql type is varbinary(128) Here's how I get the password. $p = mysqli_real_escape_string ($dbc, hash_hmac('sha256', $pass, PKEY, true)); When I echo $p it looks correct--it has weird characters. When I look at database the password is alphanumeric, without any weird characters. I think that's where my problem is but I don't know why. Here's the select query: $q = "SELECT id, purchased, username, email, first_name, last_name, agreed, sinedup, active, DATE_FORMAT(lastlogin, '%b. %e, %y') AS ll FROM $TheTable WHERE (username='$u') AND (pass='$p')";
  16. Just a suggestion, Marie. Try to debug your ipn script by either sending yourself email or writing to a text file. This is to see how far you are getting. Maybe you are not getting to the part that updates the database.
  17. Here's what I'm thinking. If I did RedirectMatch then it will issue 302 and I don't want that. If I do RewriteRule perhaps it doesn't issue 302 because I am just doing a rename, so I don't have to issue 301. If this is the case then I will do the RewriteRule. It works great and it will simplify everything for me.
  18. But won't there be a 302 done by default if I don't specify 301?
  19. Actually, I don't understand why it seemed to work before. Now the only rule that works is this one: RewriteRule ^([a-z\-]*)/?$ $1.php If I add the 301 part to it it does not work. And the RedirectMatch does not work. Maybe there is something you see in my syntax.
  20. Thank you for this good advice about putting these files into subdirectory. I will do that for efficiency. And it will organize my files also. I will always be calling the files from my program with the same name but when I started with the mod_rewrites, I noticed how convenient to let user type shorter url, etc. But I don't really need that. So for efficiency I will do what you are suggesting. It makes good sense to me. I experimented a little and changed your syntax to this: RewriteRule ^([a-z\-]*)/?$ $1.php With your syntax it gave: Internal Server Error. These RegEx are still partly mystery to me. But my rule above appears to work. One confusing thing is it works if I call url 'name' or 'name.php'. I experimented some more and I have this: RedirectMatch 301 ^([a-z\-\./]*)/?$ $1.php And an interesting thing is it works whether or not I put the \./ in or leave it out. If you think the RedirectMatch is the best way for me to do it then that's what I'm going to do. For your information, and anyone else with interest, I just found a website that explained about the 301 redirect, which we want to be using (probably). I didn't have that on my RewriteRules and if I don't put it in the RedirectMatch it will default to 302. 302s are very, very bad for SEO (from what I've read). (I know SEO isn't the holy grail but I'm doing what I can.) To add the 301 to RewriteRule add this to the end [R=301,L]. Like this: RewriteRule ^([a-z\-]*)/?$ $1.php [R=301,L] Do I still need to turn the RewriteEngine On? This is what I have now: <code> <IfModule mod_rewrite.c> RewriteEngine On RedirectMatch 301 ^([a-z\-\./]*)/?$ $1.php </IfModule> </code>
  21. I was just concerned about the time to bring up a webpage because of so many mod_rewrites. I wanted to give you an idea of the numbers of files involved, which seems like a lot to me, but it might not be a lot for the filesystem. I expect to be getting a new product line but I don't know if it will only overlap what I now have or if it will include additional to raise it from about 150 to about 400. And I don't think there will be other product lines added. The work of writing the .htaccess file is not significant, now that I'm pretty comfortable with it. I do a batch at a time. I've included at the end, what my mod_rewrites are currently, because I didn't provide enough information before. Putting these files into a subdirecty is a possibility. If that makes things easier, I think it's a good idea. But the only thing is, from what I've read, a big advantage of mod_rewrites is that my page name never has to change, even if I change my file name or location. Which is desirable for SEO and also if people have an old link it will still work. But now you're saying I should change my page name from condition-name-treatment to subdir/condition-name-treatment. But I think my confusion is because I only have limited understanding of mod_rewrites. When you write /a/something, I think you mean /a is a subdirectory of my site like this: sitename.com/a/something.php, and not outside my webfiles. Correct? Can you show me syntax of how it would work if I did subdir/condition-name-treatment and mod_rewrite adds .php to it for different condition names? But another thing I'm asking, is this something I even need to care about. Maybe this number of mod_rewrites won't slow things down. I'm not aware of any other high demands on the system. User has to login to place order but all the secure pages are separate from these product pages. My code moves back and forth between the secure pages and the product pages which don't use sessions or cookies. The only thing I've been thinking, right now they only can purchase one at a time. If I want to let them have a 'shopping cart' of some sort then I might want to have cookie remember that on the product side to pass it to the secure side. This is thinking into the future. I want to try to avoid this if I can, with my usual goal of keeping thinks as simple as possible. What other high demands might affect the mod_rewrites? As for making my site database driven, I certainly have considered that. The main reason I'm not is SEO. For one thing there are natural differences in features and secondly I also don't want my pages to look like clones with different names. Already they are highly similar. But I'm always looking for ways to differentiate. Both for SEO and also for users, who will see similar but not just a name change, page to page. So I have to type in the individual parts either into HTML or into database. The real work is in thinking up keywords and trying to find what's special about a condition or treatment. RewriteEngine On RewriteRule ^addict[a-z\-\./]*$ addiction-treatment.php RewriteRule ^allerg[a-z\-\./]*$ allergies-treatment.php RewriteRule ^alz[a-z\-\./]*$ alzheimer-treatment.php RewriteRule ^anger|rage[a-z\-\./]*$ anger-treatment.php RewriteRule ^anxi|panic[a-z\-\./]*$ anxiety-treatment.php RewriteRule ^gout|arth[a-z\-\./]*$ arthritis-gout-treatment.php RewriteRule ^emph|asthm[a-z\-\./]*$ asthma-emphysema-treatment.php RewriteRule ^back[a-z\-\./]*$ back-pain-treatment.php RewriteRule ^vir|bacter[a-z\-\./]*$ bacterial-viral-infections-treatment.php RewriteRule ^bells[a-z\-\./]*$ bells-palsy-treatment.php RewriteRule ^sunb|burn[a-z\-\./]*$ burns-treatment.php RewriteRule ^c-sympt|sympt[a-z\-\./]*$ c-symptoms-treatment.php RewriteRule ^cancer[a-z\-\./]*$ cancer-treatment.php RewriteRule ^pals|cereb[a-z\-\./]*$ cerebral-palsy-treatment.php RewriteRule ^sad|depres[a-z\-\./]*$ depression-treatment.php RewriteRule ^diab[a-z\-\./]*$ diabetes-treatment.php RewriteRule ^const|diar[a-z\-\./]*$ diarrhea-constipation-treatment.php RewriteRule ^ear[a-z\-\./]*$ earache-treatment.php RewriteRule ^faq[a-z\-\./]*$ faq.php RewriteRule ^phob|fear[a-z\-\./]*$ fear-phobia-treatment.php RewriteRule ^food[a-z\-\./]*$ food-poisoning-treatment.php RewriteRule ^genital[a-z\-\./]*$ genital-herpes-treatment.php RewriteRule ^guide[a-z\-\./]*$ guide-treat-illnesses.php RewriteRule ^health-conta|conta[a-z\-\./]*$ health-contact.php RewriteRule ^health-contr|contr[a-z\-\./]*$ health-contribute.php RewriteRule ^heart[a-z\-\./]*$ heart-disease-treatment.php RewriteRule ^heat[a-z\-\./]*$ heat-exhaustion-treatment.php RewriteRule ^hemo[a-z\-\./]*$ hemophilia-treatment.php RewriteRule ^(hiv|aids)($|[\-\./][a-z\-\./]*$) hiv-aids-treatment.php RewriteRule ^hives|urtic[a-z\-\./]*$ hives-treatment.php RewriteRule ^high|hyperten[a-z\-/]*$ hypertension-treatment.php RewriteRule ^ins[a-z\-\./]*$ insurance-alternative.php RewriteRule ^kidn[a-z\-/]*$ kidney-failure-infection-treatment.php RewriteRule ^leuk[a-z\-\./]*$ leukemia-treatment.php RewriteRule ^macu[a-z\-\./]*$ macular-degeneration-treatment.php RewriteRule ^mental[a-z\-\./]*$ mental-sharpening-treatment.php RewriteRule ^head|migra[a-z\-\./]*$ migraines-treatment.php RewriteRule ^naus[a-z\-\./]*$ nausea-treatment.php RewriteRule ^herpes|oral[a-z\-\./]*$ oral-herpes-treatment.php RewriteRule ^parkin[a-z\-\./]*$ parkinsons-treatment.php RewriteRule ^drum|perf[a-z\-\./]*$ perforated-eardrum-treatment.php RewriteRule ^preg[a-z\-\./]*$ pregnancy-problems-treatment.php RewriteRule ^prost[a-z\-\./]*$ prostatitis-treatment.php RewriteRule ^ptsd[a-z\-\./]*$ ptsd-treatment.php RewriteRule ^retard[a-z\-\./]*$ retardation-mental-treatment.php RewriteRule ^shing[a-z\-\./]*$ shingles-treatment.php RewriteRule ^sickle[a-z\-\./]*$ sickle-cell-anemia-treatment.php RewriteRule ^sids[a-z\-\./]*$ sids-treatment.php RewriteRule ^skin[a-z\-\./]*$ skin-infections-treatment.php RewriteRule ^sleep[a-z\-\./]*$ sleep-disorders-treatment.php RewriteRule ^stroke[a-z\-\./]*$ stroke-treatment.php RewriteRule ^gum|tooth[a-z\-\./]*$ tooth-gum-pain-treatment.php RewriteRule ^tremor[a-z\-\./]*$ tremors-treatment.php RewriteRule ^tumor[a-z\-\./]*$ tumors-treatment.php RewriteRule ^pertus|whoop[a-z\-\./]*$ whooping-cough-treatment.php RewriteRule ^wound[a-z\-\./]*$ wound-healing-treatment.php
  22. I've been thinking about my ModRewrites. I am adding new files every day. There will be about 150 total. But I might be adding a new product line that could increase it to about 400. I'm not sure until I get details and I don't know if that matters. What I'm thinking about is that all these modrewrites are going to slow things down. What I'm doing now works great and it gives user ability to type abbreviations. But if it will slow things down, should I even do it that way? What I really only need, is when my program calls up a name, the modrewrite finds the correct file. My program uses the canonical name which is what I want. Would it make sense for me to do this, if this can even be done: All my file names start with a condition name followed by hyphen followed by treatment.php: condition-name-treatment.php, and my code calls the file without the .php. Could I say [a-z\-] followed by "-treatment" gets .php added. If this can be done would it be faster? So would it be worthwhile doing? I should mention there are a few other files that don't use the condition-treatment format so this modrewite shouldn't catch those. Here is example of what I do now: RewriteRule ^head|migra[a-z_\-\./]*$ migraines-treatment.php
  23. It appears that would work. Providing you are checking they are not already paid, in case they try to register when they are already paid. And providing you are sure there is not another person with same username. I assume you have the right checks in place. Looks good to me -- I hope it works out for you.
×
×
  • Create New...