owatagal
-
Posts
212 -
Joined
-
Last visited
Posts posted by owatagal
-
-
You could probably drop off that first backslash too, then, because it was escaping the period in the original bit of code.
Pesky periods... glad it worked, though!
-
I'm trying to do the opposite of what you're doing--I want www.example.com to redirect to example.com. This code works for me:
>RewriteEngine on RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC] RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]I have it in an .htaccess file at my site root. Instead of going through CPanel's redirect option, open the File Manager, navigate to /public_html/, and if you don't already have an .htaccess file create one (use the create new file link, then just call it .htaccess with nothing in front of the .)
Then you'll need to reverse the above code, which I think would look like:
>RewriteEngine on RewriteCond %{HTTP_HOST} ^\.example\.com$ [NC] RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]Open your new .htaccess file and paste the above in the file, and it should work for you.
A word of warning--if you already have a lot of redirects going on, this may not work. I know of at least one folder on my site that is having problems with this redirect clashing with another, and the server has decided to just send me back to the home page instead of to the page I expect.
But if you don't have any other redirects going on, then this should be ok.
-
It looks to me like the links are centering themselves in the space that is left after the login/register list goes up. To center them on the screen itself, you need to find a way to convince them that an equal amount of space is taken up on the right side as the UL takes up on the left.
Whatever you do, I think you're going to have to give your UL a specified width. And then you can try adding right-padding to just the last item in your other menu to mimick that width.
The markup would look something like adding:
#Toplink ul {
width: 200px;
text-align: left;
margin: 0;
padding: 0;
list-style: none;
}
#contact {
padding-right: 200px;
}
If you need the ul set wider, set the #contact padding wider as well. That might work.
You're going to have to play around with it a bit, I think. And I'm not sure what your -200px margin on the UL is doing right now--it looks like it's just there to keep the list from centering? it's better to use something like text-align: left; and a set width in that case, I think.
I hope this will work, anyway.
-
Do you have a link to the page? I have a hunch, but it depends on the information in the rest of the style sheet. It would also help if I could see the page (because I'm visual that way).
-
Are you sure it's a problem with the mobile device and not javascript generally? Since your code ends with the </select> button, it isn't clear if you have a submit button built into the form. Do you have a non-javascript version that works on websites? Or does the menu always stop working if javascript is turned off?
If it is a case of javascript, check out WebDevTips' jump menu:
http://www.webdevtips.com/webdevtips/codeg...ickgoplus.shtml
When a user has javascript turned on, the jump menu works like you want it to--pick an option and the form submits automatically. But if javascript is off, you get a submit button instead.
You'll probably have to modify the code a bit, since you've already built some javascript in there, but I use a variation of this on one of my sites for something similar--pick an author, a menu with all their books pops up kind of thing. It works well.
I think it should work for you--since you mentioned adding a "go" button as a possible solution.
-
I don't know about the error specifically, but right now the PHP has a second opening tag in the middle of it and the html within the brackets isn't set up to actually do anything--the PHP engine is trying to render it as PHP and not HTML, I think. Which could be enough to trigger that error.
Try:
><font face='Verdana' size='1'>Welcome Back <?php print $_SESSION['user']; if ($_SESSION['permission'] > 1) { echo "<a href='modUser.php'>mod user</a>|<a href='delUser.php'>del user</a>"; } ?> </font>One word of warning--the way it's set right now, it would be possible for someone to randomly set up a permission value of, say 1000, and it would print out this bit of menu. If you know the actual permission values of your admin users, it would be better to set up something like
>if ($_SESSION'permission'] == (1|2|3)) {I'm not certain that's the exact syntax, but something like that would be more secure--look for an exact permissions match, instead of "any number greater than 1."
-
To answer my own question, yes it's possible to use YourSQL.
This thread helped out--
After adding my home machine as a valid user to the database (through CPanel), I was able to connect using example.com as the server, specifying the database I wanted to connect to, and using the right username/password for the database, not CPanel.
So, yeah, next time I'll research before I ask a question that's already been answered... !
dkotchen, you might find YourSQL or NavCat a little more flexible in terms of dealing with the data. They're still GUI, but it's a little easier to customize things.
-
Along a similar vein-- Is it possible to use YourSQL or NavCat instead of PHP MyAdmin? I prefer them because there's more flexibility in queries and they seem to run faster for me. If it is possible, what would the server address be? I assume the user name and password would be the general CPanel user name and password?
Or are we blocked from using them because of the way CPanel and MyAdmin are set up?
-
Disclaimer: This is a very, very, very basic data check. You should not rely on it and assume data that passes this test is 'safe'. You should use it in combination with other data checks. If you already have other data checks in place, you'll need to test and make sure it doesn't clash with or override them--that would be bad! The good news is you should be able to drop this into your existing form easily, without having to modify your entire results script.
Ok, so you have a form. Maybe you're getting people to send you email addresses for a newsletter:
><form name="myform" method="POST" action="path/to/my/results.php"> Enter your email: <input type="text" name="email" /> <input type="submit" value="Sign up for the newsletter!"> </form>
Your form can look like whatever you want; what I’m going to show you can easily be incorporated into a form you already have, because you're just going to add it at the top of your results page.
On your results page, you have to call up the variables that were submitted in the form. You probably do this one of two ways.
You may be relying on register_globals being ON (which it is by default) and so you just refer to the variable by name when you need to use it:
$email
The problem with this is that you don't know if the variable was submitted through POST, GET, or anything else. Yikes! If you don't know where the information is coming from, it's going to be even harder to verify that it's legitimate data! Fortunately, we can solve that problem without even turning register_globals off (personally I think you should turn it off anyway, but some people rely on it for other codes).
Or maybe you already have register_globals turned off, or maybe your code is written as if it is off. In that case, you call your variable like this:
$email = $_POST['email'];
And throughout the rest of the script, you do whatever it is you need to do with the form information--mail it to yourself, echo it out for the visitor, whatever.
The first thing we're going to do is pop a function at the top of your results page (after the opening PHP tag, of course). This function will allow you to cut a variable down to whatever size you specify. Just paste the following at the top of your PHP code (you don't need to modify anything):
>function set_text_limit($variable, $limit) { if (strlen($variable) > $limit) { $variable = substr($variable, 0, $limit); } return $variable; }This function will check the size of a variable and if it is larger than the limit you define, it chops the data off at your specified limit. Like I said, it doesn't verify what is or isn't in the variable; it just ensures the variable is a certain size. How does this help? Well, if someone is sending you an email address, there's no reason to let them send you 1000 characters of data. And you can't rely on your form itself to limit the length of data, because it’s very easy to spoof form data and send you information that never went through the form at all--or went through a modified version of your form that had those checks removed. Best to check on the server side!
Ok. Now you're going to define your variable. For each of your variables you write a line like this. You need to add this line in after the function script you just put in:
>$email = (isset($_POST['email'])) ? set_text_limit($_POST['email'], 75) : '';
This should replace any lines like this:
$email = $_POST['email'];
(If you never defined your variable, but just called on $email, all you need to do is add the new line after the function script).
Where it says set_text_limit($_POST_'email'], 75), you should change "75" to the number of characters you would like to allow. Each variable field can have a different limit. For a name field, 40 or 50 is probably more than adequate. For an email field, 50 is probably fine. For a URL field, you might want to allow 75. Even for textarea fields you should set a limit--and remember, the limit is on the number of characters, NOT the number of words.
What this code does: First it checks that the POST field is set; if it is, it limits the post field to the number of characters you specified and assigns that value to the variable. If POST is not set, the variable is given a null value. This means that if someone tries to send you a value for the 'email' field through the GET parameters, it won't work--the null value in this line of text should override anything they send as GET. The only way to set $email with data is to send that information through the POST method. (Obviously, if they spoof the POST method, this won't help. This is why you need to verify your data in other ways as well!). And since you can set the variable name to whatever you want, you can use the same variable names you're already using.
The only major modification you might need to make is if you consistently use $_POST['email'] or $_GET['email'] throughout your results page--you'll want to replace all of those with the variable you create in this line ($email in the example). And although I've used $email as the example, obviously this should work with any field names/variables your form actually uses. Just make the relevant adjustments.
Again, don't rely on this as your only data check! But I hope, if you're just starting to learn how to secure your form and verify all the data, it might be helpful.
-
dbarak,
My error pages are all .php
I also don't know if domain propogation has anything to do with it, but I do know I have problems with my FTP program sending .htaccess files in the wrong mode. I'm too lazy to edit the configuration files, so I do all my .htaccess work through CPanel's File Manager.
My guess is that if you uploaded the .htaccess through your FTP program, and it sent it in the wrong mode, you're seeing the file in File Manager but the server can't read it (because it's corrupted or whatever happens when FTP transfer is done in the wrong mode). Delete it in File Manager and then recreate it (again, in File Manager) and see if that solves the problem. File Manager *does* handle .htaccess in the correct mode.
Otherwise, see if it fixes itself when the domain propogates. But the fact that it's PHP shouldn't affect anything at all.
-
Hi Bruce and David,
Thanks for the info--good to know. I'll check out the links--now I have a better idea of what I'm looking for.
I did think about using an available platform when I first started, but I wanted to learn to code better, so the blog seemed like a good playground. As I learn more, the blog gets new features. And every once in a while it goes completely overhauled because I've learned better and/or more secure ways of doing things. So adding trackbacks and pings, even if it's a lot of work, is at least half the reason I have a blog in the first place because, yeah, I think I'm a geek. Or at least a geek wanna-be.
-
8point2,
I think what you're saying is that you have some sort of main content box with a drop shadow (on the left and right?) that you've set to specific heights -- say 600px. And so when you increase the text size, the window scrolls but because you set the drop shadows to a specific height they don't increase. Is that it?
If it is, take a look at A List Apart's faux column layout:
http://www.alistapart.com/articles/fauxcolumns/
This has you use a background image that repeats down the page--it's still just 1px high, but it's however wide your content is. You don't set the height, so it adjusts with your content; it'll always go to the bottom of the page. Pretty elegant setup, actually.
-
I was thinking about adding trackbacks to my blog when I realized I don't even know if trackbacks work cross-platform. Are trackbacks a general technology, like RSS feeds, that can be used on any blog? Or do they only work within a specific platform, Moveable Type users only tracking MT users and Wordpress only tracking Wordpress users? I understand what trackbacks do, I just have no idea how they work at the scripting level. Since my blog is homegrown, I'm not sure how much of a headache it would be to find a working script, change it, and incorporate it into my system. Anyone tried doing this?
Along the same topic, does anyone know of a generic RSS feed generator? I've looked into RSS enough to know that I could write all the feed by hand (blah), but I'd rather have something that could update the feed automatically when I write a new entry. I know I should go over to Hot Scripts and look, but as long as I'm asking about trackbacks I thought I'd see if there are any ideas on RSS feeds as well.
Thanks!
-
Actually, my code just had an extra space in it, and I should have used the short opening tag like so:
<?=$_GET['nop']?>"
And it doesn't need a semicolon (to run) since it's just the one line.
See the bottom of this manual page: http://us4.php.net/echo
Interesting & good to know. That will come in handy elsewhere, I think.
-
noiz,
are the style sheets on your subdomain or main site? Have you tried switching back and forth between relative, root path, and absolute URLs to see if any of them work?
-
I think you're going to alter matman's code a little, because it isn't telling the PHP to actually do anything with the $_GET value. And it needs a semi-colon:
><b>Name of Pet: <INPUT name="name_of_pet" value="<?php echo $_GET['nop']; ?>" style="HEIGHT: 22px; WIDTH: 310px">
-
If you want to PM me and let me know what exactly was in the .htacess file when you got the first redirect to work (http://wiki.yoursite.com/index.php/Main_Page), I might be able to help you work out the RewriteRule thing. It's just hard to know what's going wrong since I don't know exactly what you're using.
You could also try http://forum.modrewrite.com/ ; I was able to fix several problems reading through their forum. They might be able to help you out.
-
Unless your pages are password protected and/or you use forms instead of displaying email address, the bots can almost certainly pick up the addresses. It's difficult if not impossible to display an email address to your visitors in such a way that a bot can't pick it up. But you can make life more difficult--munging the address can help:
>if ($email != "") { $email = trim($email); $email = preg_replace("/@/", " [at ] ", $email); $email = preg_replace("/\./", " [dot] ", $email); echo "<br>Email: $email"; }I haven't tested the code, but in theory it should work. Well, if I got the regular expressions right. This should output:
Email: username [at] domain [dot] ext
Alternatively, you can use hex encode to "hide" the address from bots while displaying it to visitors -- see PHP's bin2hex function (http://uk2.php.net/bin2hex). But bots can figure that out as well as (better than?) munging. Personally I use munging, with non-standard phrases (i.e. not [at] or [dot], both of which are easy to guess and look for from the spammer's perspective). Neither method is fool-proof, but either is better than nothing, you know?
-
Ok, try this:
RewriteBase /
RewriteRule ^(.*)$ /index.php?variable=$1
This is almost the same as before, but take the slash out of the RewriteRule.
Again, I'm assuming you're putting this .htaccess file in the /wiki/ folder and that you're changing the index.php?variable to whatever is relevant.
If that doesn't work, try
RewriteBase /
RewriteRule ^(.*)$ http://wiki.******/index.php?variable=$1
And if that doesn't work, then I'm guessing something in the fact that you have a subdomain is messing up the write rules. But see what happens.
[edited to point out that the subdomain isn't at fault as much as my limited knowledge is]
-
Do your error logs say what URL it was trying to access when it got the 400 error? That would help sort out how the RewriteRule is actually rewriting the URL and what would need to be changed.
-
You're trying to rewrite a dynamic URL to look like a static URL, and you want to hide the actual dynamic URL from visitors, right?
Is your .htacess file in the /wiki/ folder? (This idea assumes it is)
If so, I think you should be able to use
RewriteRule ^/(.*)$ index.php?variable=$1
Where variable is the PHP variable you use on your index.php page. It won't be visible to site visitors, who will only see wiki.******/Main_page -- at least, that's all they'll see if you always use wiki.******/Main_page as the link and don't use the wiki.******/index.php?variable=Main_page as a link anywhere.
I think. I use a similar rule, but it isn't in a subdomain. I don't know how that would affect things.
The problem with the RewriteRule I just offered is that it's going to take every URL starting from the /wiki/folder and try to rewrite it to index.php?variable=/whatever/folders/you/have/in/the/link
Not a great idea, if you plan on having any subfolders in /wiki/
In that case, you probably need an identifier of some sort, so you can specifiy which URLs get written to this index file:
RewriteRule ^/a/(.*)$ index.php?variable=$1
/a/ can be any identifier you want it to be, as long as it's not the name of a real sub folder.
I'm not guarunteeing this will work, but the problem looks similar to something I tackled on my blog, and this is how I got around it. But I don't have a subdomain in there. And my .htaccess file is located in the /blog/ folder, which is where all the redirecting starts. And I'm not an .htaccess expert, but it looks to me like the problem is you aren't defining which part of the fake URL needs to be rewritten onto the new URL -- that's the $1 bit. And that's the end of my disclaimers.
Someone with a better grasp of .htaccess may be able to offer a more elegant solution.
-
I've realised that the book does say to include the
>$name = $_POST['name'];
at the beginning of the script, but they only say it in a small box because they try to get you to turn on some setting on the server to recognise the items automatically.
Thebook is called something like;
PHP5 / MySQL
for absolute beginners - that's me
so onto the next page
Andy
They're probably trying to get you to turn register_globals on. Actually, that's the default setting at TCH. It is more convenient, but it means you have no idea where the information is coming from-- if you have a form with method=POST and a field called email, and on your results page you just call the variable $email, you can't be sure the information came from your form--it could have come from anywhere. Nothing can replace initializing and verifying your variable data (if your form has a drop down list with four options, you should ALWAYS check to make sure that the variable actually equals one of those four options--even if the variable comes through POST.) Never assume a variable is safe, whether register_globals are on or off. PHP.net has a good explanation of how register_globals affects things:
http://uk2.php.net/manual/en/security.globals.php
I'm a fan of register_globals off just because it gives you more control over where the variables are coming from--it's not a cure-all solution, but every bit of control is a good thing, I think. If you want to turn them off for your site (since TCH has them on by default) just add
>php_flag register_globals off
to your .htaccess file. And then while you're working your way through the book, remember to call all your variables with $_GET or $_POST -- less convenient, but better practice in the long run.
-
Email verification could work. I can just whitelist certain IP addresses that I know comment often so they don't have to go through it.
I thought about the random string thing, but anything I can write a program to get around I don't want to do--if I can hack it, it's a bad thing, you know?
I'll definitely check out the link--looks great! The logic test is a good idea. I saw something similar on another site--an extra form field asking "What is Diana's first name?".
I doubt any comment spammers would ever actually *want* to target my site anyway--no trackbacks, and all comment URLs include the rel="nofollow" tag, and it's homegrown code so they have to work extra hard to find it (can't search for known files). They'd be doing a lot of work and wasting their time--boy, do I love the thought of them *really* wasting their time by trying to find a way around extra security measures. And if no one bothers, I still know more about security then I did before. Everyone wins (ok, I win).
I'll go see what the W3C has to say.
-
Aside from captcha images, what methods are available to validate that form users are human and not bots/programs trying to flood the form? I'd like to avoid captchas if possible because they aren't handicap accessible.
It's not a problem with validating the form data itself, because spammers can easily spoof valid data. How do you verify a user is human and not a machine drone trying to flood the comments without captchas?
Javascript is right out--too easy to turn off. If sessions were effective, I'd think people would be using them instead of captchas. But I suppose sessions would be better than nothing, especially if they were tied to a database &extra random numbers.
Anyone have any ideas? I'm not necessarily looking for code examples, just thoughts on how to verify a human user without resorting to images. Not that I'd turn down code examples, of course!
Navication Issues
in HTML and CSS
Posted
Yeah, IE figures out the total width of a box differently than everyone else, which is why I was thinking the 200px padding should add on to the last link and not the TopLink. But that wouldn't work, because there was more than 200px there anyway.
You can do a hack on IE box model widths, if you want--just search for IE and box model hacks and you'll see any number of answers. The code below is a different type of hack--basically, adding an empty paragraph to the right site of the menu which can balance out the UL on the left. It's not elegant, it's not perfectly semantic code, but it works. You'll notice there's no link formatting or anything--you'll need to work this code back into your original.
>The CSS: #TopLink { width: 800px; } #TopLink ul, #TopLink li { padding: 0; margin: 0; list-style: none; display: block; } #flleft { float: left; width: 200px; text-align: left; } #centered { margin: 0 auto; } #centered li { display: inline; } p.sham { float: right; width: 200px; } And the HTML: <div id="TopLink"> <ul id="flleft"> <li>[<a href="modules.php?name=Your_Account&redirect=index" class="top">Login</a>/<a href="modules.php?name=Your_Account&op=new_user">Register</a>]</li> </ul> <p class="sham"> </p> <ul id="centered"> <li><a href="index.php" id="home">Home</a><b>|</b></li> <li><a href="modules.php?name=Forums" id="topics">Forums</a><b>|</b></li> <li id="last"><a href="modules.php?name=Contact_Us" id="contact">Contact Us</a><b>|</b></li> </ul> </div>I put your other set of links in a list as well, but that's my personal semantic preference. You could probably play with it and get it back to just <a> links. The sham p-tag does need to appear before the centered UL in the code, because it floats over the top. If you put it after, it drops on the next line in some browsers.
I tested in Netscape, Firefox, and IE on Mac. Since it works on IE on Mac, you should be ok on PC. Or at least at a point where you can fiddle with it.
If this is a PHP page, you could turn the sham-p into something real, like
><p class="sham"> Today is <?php echo date('d-m-Y'); ?>Anyway, hope that helps some.