scanreg

thanks the main thing is that we'd like to display cart contents and other cart features to just the authenticated user

Ah, thanks, so perhaps requiring login first would be better per ChristianF

yeah, was thinking that too, though wasn't aware that users can change ip on a per request basis, thanks for that info any thoughts on how to better approach this? thanks

well, i'm thinking that perhaps it would be good to tie the session to the originating ip if original-ip + session, then display good stuff else bye since the ip is merely detected by the server but not sent in the data stream

thanks both 1. if you set to delete the old session: session_regenerate_id(TRUE); does this delete just the session id, or does it delete all the data associated with the old id too? there's a comment over in the php.net link mentioned by lemmin that states: session_regenerate_id(TRUE); /* erase data carried over from previous session */ so i'm concerned that all the data would get zapped too 2. what if you had the same scenario mentioned originally but now the session_regenerate_id is set to delete the old id (or id and data, whichever it is) (TRUE), what if the original user triggers a session regenerate first, thus deleting the old session id, but the bad guy after that then clicks a page, what happens to the bad guy? does it generate a session id but that new bad-guy session is untied to the original user, thus keeping the bad guy out? thanks

session_regenerate_id what if a bad guy traps a session id and then goes to that site and clicks something on that site before the original user triggers a new session id? (original user is just sitting on a page for instance) might the bad guy trigger a session regenerate first and thus block out the original user? thanks

Will this safely convert all existing data, or is this just for inserting new data? Thanks

If possible, it might be easier to keep everything that needs to be over SSL in the same sub-directory and just require ssl for that directory. Perhaps someone a bit more familiar with rewriting could provide some rewrite based options. Another thing you could do is just force everyone to use SSL for the entire site rather than try and pick-n-choose just specific pages. I wish I could (1) have a secure directory to store those items in but no luck, gotta rely on the dynamic shopping cart pages for those items and (2) run the whole site via SSL, but no luck, gotta have a non-ssl home page and the generic info pages and most product pages Here is an example of the dynamic item page URL: http://www.mysite.com/index.php?main_page=product_info&cPath=22&products_id=34 Think I could do something like this? : SSLOptions +StrictRequire SSLRequireSSL ###SSLRequire %{HTTP_HOST} eq "site.com" #or www.site.com ###SSLRequire %{HTTP_HOST} =~ m/(www\.)?site.com$/ SSLRequire %{HTTP_HOST} =~ m/(www\.)?site.com/index.php?main_page=product_info&cPath=22&products_id=34$/ ErrorDocument 403 https://www.site.com/403.shtml However, sometimes there is a session id on the end too, not sure how to allow the session id, which changes per user Thanks

I need to force SSL on some subdirectories and on some specific pages in a shopping system The specific pages might be static but they also might be dynamically created through the shopping system I found the following htaccess code to force ssl for an entire domain: http://wiki.dreamhost.com/Htaccess_file_overview SSLOptions +StrictRequire SSLRequireSSL SSLRequire %{HTTP_HOST} eq "site.com" #or www.site.com ErrorDocument 403 https://site.com 1. How can I get this to cover both http://site.com and http://www.site.com ? Should I just add a dot in front of the domain?: SSLOptions +StrictRequire SSLRequireSSL ###SSLRequire %{HTTP_HOST} eq "site.com" #or www.site.com SSLRequire %{HTTP_HOST} eq ".site.com" #or www.site.com ErrorDocument 403 https://www.site.com 2. How can I get this to cover the specific dynamically generated shopping cart pages that I need? Not all cart product pages, just several specific ones. I'm guessing this would be some sort of Rewrite feature in the htaccess file. I found the following: http://www.phpfreaks.com/forums/index.php?topic=320065.msg1508331#msg1508331 RewriteEngine On # Send everyone in these dirs and pages to https RewriteCond %{HTTP_HOST} ^www\.somewebsite\.com$ [NC] RewriteCond %{REQUEST_URI} clubs [OR,NC] RewriteCond %{REQUEST_URI} dealer/ [OR,NC] RewriteCond %{REQUEST_URI} login.html [OR,NC] RewriteCond %{REQUEST_URI} dealer_registration.html [OR,NC] RewriteCond %{REQUEST_URI} club_registration.html [OR,NC] RewriteCond %{REQUEST_URI} contact.html [OR,NC] RewriteCond %{REQUEST_URI} dealer_club_contact.html [OR,NC] RewriteCond %{REQUEST_URI} members [OR,NC] RewriteCond %{REQUEST_URI} secure/ [NC] RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L,QSA] However, is there a way to force ssl for specific dynamic product pages in a shopping cart using SSLRequireSSL instead of mod_rewrite? According to the first thread mentioned, Apache gives mod_ssl priority over mod_rewrite, thus the interest in forcing all SSL using htaccess and mod_ssl Thanks

i understand, it is off too i'm just trying to understand in my pea brain the difference between $GLOBALS and superglobals is it, for instance, that superglobals work whether or not register_globals is enabled (so you have to name a variable to use it), but $GLOBALS only works if register_globals is on (thus allowing anything to be registered as a variable)? sorry for making a mountain out of what i'm sure is a simple thing but i've been reading and reading but sadly haven't figured out yet the distinction between $GLOBALS and superglobals, that's kinda what i'm trying to clear up i guess thanks

ah, so unsetting all the $GLOBALS versions of those keys is what is done, but leaves all the superglobals to contain the keys what is the advantage, then (if i'm correct), of still having all those same keys in their respective superglobals (but now filtered out of $GLOBALS)? i know generally that it's good to not allow register_globals so that you don't get stuff like input name=authenticated value=1, but beyond that, what am i missing? why is it good to unset all $GLOBALS but still allow all the superglobal versions of those same keys? thanks

yes, i am aware of this and is done but just trying to understand the protection against register_globals am i correct in thinking that in the case of the function above, if register_globals is on that all incoming data would definitely be killed? in other words, if register_globals is on and the function above is run that there would not be any form or other data available, it would all be unset and unretrievable? thanks

i'm trying to understand unsetting all globals in form data but still having the desired form data available i've read the following several times but i'm stuck: http://php.net/manual/en/security.globals.php how can you first unset all GLOBALS, _REQUEST, _POST, _GET, _SESSION, and the others, but still be able to retrieve the correct form fields and other needed data? for example (taken from page above), if you run the following: <?php // Unregister_globals: unsets all global variables set from a superglobal array // -------------------- // This is useful if you don't know the configuration of PHP on the server the application // will be run // Place this in the first lines of all of your scripts // Don't forget that the register_global of $_SESSION is done after session_start() so after // each session_start() put a unregister_globals('_SESSION'); function unregister_globals() { if (!ini_get('register_globals')) { return false; } foreach (func_get_args() as $name) { foreach ($GLOBALS[$name] as $key=>$value) { if (isset($GLOBALS[$key])) unset($GLOBALS[$key]); } } } unregister_globals('_POST', '_GET', '_COOKIE', '_REQUEST', '_SERVER', '_ENV', '_FILES'); ?> haven't you just killed all incoming data, good or bad? how do you then retrieve the desired good-guy fields if you've just zapped all the form stuff? thanks

Thanks, I'll check out that pdf, great I have a bunch of pages that are no longer part of the site anymore, hence the not-found issues I was thinking of having all those 301 redirects point to the home page Think this would be no good? Otherwise, I can't think of a solution cuz that content is not on the site at all any longer and I'm guessing that posting dummy pages would not be good either. Thanks

WinSCP http://winscp.net