jhsachs

I need to make my client's site distinguish among different tabs in the same browser. (See http://www.phpfreaks.com/forums/index.php?topic=357772.0 for background.) I create a tab ID when the user first visits the site in a particular tab, and I'm passing it from page to page as a parameter. This seems to be the only way to do what I need. The tab ID is always passed through POST so that the user won't see it. If it were visible, users could make trouble (or more likely get in trouble) by adding or removing the ID themselves. This is not simple where a page is loaded by a hyperlink. The anchor tag passes parameters via GET, period. The solution I found is to link to a script named post.php, which takes the real link target and the tab ID as parameters, sends the browser a form that passes the tab ID to the real link target via POST, and auto-submits the form via JavaScript. This works, but it requires two round trips to the browser to load a page. It's also a pain to code. Is there a more efficient way to do this... perhaps a way to make the server send the browser a POST response, even though it made a GET request? If it matters, the server is Apache 2.x.

I'm working on this now. The tricky part is making all of the links and non-form buttons pass a token via POST. I've figured out how to do that, but like I said, it ain't pretty. Actually it's a toss-up. The web site's purpose really doesn't admit any sensible reason to do that. If anyone tries, it's either because they don't understand what they're doing, or they're trying to do it just to see if they can, or they're trying (probably without hope of success) to pull a fast one on the site owner. I haven't decided which way to do it, though. The design is virtually the same either way; I don't have to choose a design until I'm almost done.

My client's customers have been experiencing mysterious and upsetting malfunctions which, I finally figured out, are caused by accessing the web site through two tabs at once. The site uses session variable to maintain status information. A user visits the site, starts a session, and does a considerable amount of work, which adds information to the session variables. Then the user starts another session, which wipes the session variables clean. Then they return to the first session and load a page which expects to find all the information which was added by the pages which had to be used to get there... and it's all gone. We'd be happy if we could either keep the two sessions separate or prevent the user from starting the second one. Without being able to distinguish between the tabs, though, it's impossible to do either one of those things. I've pretty much decided to do what you said -- pass a token from page to page -- but it won't be pretty.

I need to be able to identify the browser tab that sent each request the server receives. I originally planned to do this by passing an ID back from each web page. However, I found that when the user leaves a web page by clicking a non-form button or a link, this causes huge problems. The ID really has to be returned via POST to prevent users from using it inappropriately, and the prospect of making a button or link do a POST is not appealing. Is there any other technique I can use? I've examined all of the superglobals, but I didn't find anything that would work.

The problem: when the site loads a page using HTTPS, the new page is loaded but $_POST is empty. I figured out how to fix it, but I'm posting for two reasons. First, to ask for insight into why the problem happened. Second, to help anyone who encounters the same problem. I first tested the site with a temporary URL provided by the hosting service. This had the form servername.hostname.com/~accountname. For this test I used a self-signed certificate which covered servername.hostname.com. Everything worked. Then I assigned the site its own domain name, created a certificate for www.owndomain.com, and tested again. That is when the problem occurred. The cause: I was generating the URL of the HTTPS page without a server name; that is, in the form https://owndomain.com instead of https://www.owndomain.com. I have a rewrite rule that rewrites owndomain.com to www.owndomain.com, and I suspect that has something to do with the problem. I believe a rewrite rule must explicitly incorporate parameters into the rewritten URL if it wants them, but since I'm using POST, not GET, I shouldn't have to do that (and can't). More experienced developers, please: any insights into what happened?

You might try a different business model that solves your most worrisome problems without creating too many new ones. For example: charge for resources used instead of a flat fee per user per month. This would solve the problem of account sharing, not by preventing it, but by making it pointless. If that doesn't work for you, maybe some other innovation will. The important thing is to see whether thinking outside the box will help.

It doesn't work that way, but it shouldn't be hard to generate a new key if none is provided. Session management is already handled in a .inc file that all of the scripts include, so that shouldn't require much redesign.

That sounds like a pretty good solution. I assume there would be no problem using POST instead of GET? (I'm concerned that a user might try to launch a new session by copying the URL from one window to the other, which would defeat the mechanism if it used GET.)

I've got a site that requires the user to follow a well-defined workflow, corresponding to a sequence of pages. You'll have the right idea if you think of a store where the user selects items, then chooses a delivery method, then pays (although the site's actual purpose is somewhat different than that). I just tracked down a puzzling logical failure: a user followed the workflow up to a certain point, then opened a new browser window, pointed it to the site, and started a second workflow. The site stores information about the user's activities in session variables, and the two windows shared a single session, so the site got tremendously confused about what the user was doing. Given the site's design, visiting the site in two windows at once is a legitimate thing for a user to do. I'm darned if I see how I can accommodate it, though. Other designers must have dealt with this problem many times. What ways of solving it have been found effective? In this case, the simplest and most effective solution would be to create a new session for each window in which the user visits the site. Is there any way to do that?

Thanks for the varying perspectives. I'm going to respond to just a few of the comments. KIS is a good principle, one which I try to adhere to (and which my boss often tells me to consider after I think I've pushed it as far as I can). In this case, however, I'm developing my standard largely by taking ideas from several established standards: PEAR Coding Standards, CodeIgniter General Style and Syntax, and Drupal Comment Formatting Conventions. Most of my work has consisted of cutting. My document is shorter than any of my sources, despite the fact that I'm borrowing concepts from all three. So, how simple should simple be? Judging by the standards I started with, I think I've done a darned good job. The document is still longer than I'd like (13 pages, or 8 pages without the examples and front matter), but it's not clear what can be cut without real loss. Evidently I put more emphasis on the role of spacing in legibility than many other programmers do. I don't think it would be useful to debate who's "right" and "wrong"; I'll just observe that I developed my own practices over decades by observing my experience with my own code and others'. No one is going to convince me that spacing isn't important to me. I've had too much experience having to reformat other programmer's code before I could make sense of it to believe that. Finally, I just don't know what to make of the comment that spacing doesn't matter because "Any modern IDE/editor has syntax highlighting (and bracket matching)..." There's a huge difference between being able to understand what a piece of code does by looking at it, and finding that that bracket in this statement matches this one because the the editor highlights one when I put the cursor on the other. It's the difference between looking at a room through a door and looking at it through a keyhole.

I'm writing coding standards for my organization, and I'm facing an issue of when to use spaces that has long troubled me. This may seem trivial, but within the topic of standards, the trivial becomes important. Virtually every programming standard I've ever seen allows no spaces between the first or last parameter in a function call and the adjacent parenthesis: function($parm1, $parm2, $parm3); I've never seen a reason given for this. On the other hand, there are substantial reasons why it is bad practice. First, it implies that the first parameter is more closely associated with the function name than with the other parameters, which is absurd. Second, the close parenthesis tends to merge visually with the last parameter, making it easy to misjudge where the parameter list ends in a complex expression. Third, if the last parameter is complex enough to require parentheses, it makes the code much more difficult to understand: function($parm1, $parm2, round(($upper+$lower)/2+0.5)); My own rule is that if the parameter list is complex enough to benefit from spaces, spaces should be inserted between parameters, before the first, and after the last: function(parm1,parm2,parm3); function( $parm1, $parm2, round(($upper+$lower)/2+0.5) ); I'd like to hear others' comments on this before I decide whether to tell my organization to do what the rest of the world does, or try to make it do something totally nonstandard that (in my judgment) yields better code.

I'm trying to write this in a diplomatic way, but the message makes that difficult. Please bear in mind that no offense is intended. You can't answer my question because you don't understand the basic principles of security, in particular, the concepts of mitigation and layering. I'm writing this because you can get in a lot of trouble if you try to work on a web site that has security issues and you don't understand them -- or don't at least understand that you don't understand them. I don't want you to get in trouble, at least not because I took the easy way out and walked away from this thread. I'd encourage you to get a basic understanding of this topic. The PHP Security Consortium, http://phpsec.org, is probably a good place to start. The most important information is not PHP specific, though, and may be best found elsewhere. I'm sorry I don't have a set of references handy. If there's interest, I'll make a point of finding some.

It seems to me that this should be easy, but I can't find it in the manual or the on the web, and the values in $_SERVER don't suggest anything. Context: script A loads script B using HTTPS. Now script B has to load resources (images, style sheets, etc). Browsers often object to HTTP references from a script run by an HTTPS request, so script B should generate URLs that use HTTPS. Thus it has to know that it was loaded with HTTPS. I can do this by brute force if I have to (defining a "protocol" constant in the script itself), but I'd rather make the test automatic.

I checked it out. The file is 'hosts'. I made the change, and it works. Strange. For WinXP they said not to put localhost in hosts, or at least went out of their way to say it didn't matter. Now it does. Thanks for helping me solve this. The connection between symptom and problem was so tenuous that I might never have found it on my own.

I'm not at my own computer now either, but... be aware that I have no trouble with localhost in the browser's address box, or in other PHP functions that expect URLs. Is this a likely solution despite that?

That works. Very interesting... but not quite a solution, since mPDF derives the URL by adding http://localhost/subdirectory/ to a relative URL taken from a <style> tag. For the grand prize, can you guess why localhost makes it hang when 127.0.0.1 does not?

Yes, when I run mPDF it hangs. (If it didn't I wouldn't be here, because I would not have a problem! :-) ) "Hang" means that the function never returns control to the script. Eventually the browser times out and I get an apparently complete page load with an empty display. There is no error message from PHP and no timeout from the server. If I'm running the debugger when I do this, I can't start the debugger again unless I restart both the IDE and the browser. That suggests that some part of each component has been left in an undefined state, but that doesn't suggest a possible cause to me. I tried reading a remote page as you suggested, and it works. I tried reading a different local page and it hangs, so the problem appears to be associated with local URLs. That's progress, but I it doesn't suggest a possible cause either.

I'm not sure what you mean by "go to." To me, in this context, "go to" means "load" (into the browser). When I load that URL into the browser it displays the contents of the file. If I try to read the file from that URL in a script, it hangs, as I said. If I load an HTML page that refers to that location, it works normally. (The script actually loads an equivalent relative URL... if that's what you meant, and the difference between a relative and an absolute URL is significant, let me know, and I'll try it.)

I recently migrated from Windows XP to Windows 7, and a PHP package I depend on (mPDF, see http://www.mpdf1.com/mpdf) stopped working. When I call one of its necessary functions, it hangs. I investigated further and found that the crash was happening in a call to file_get_contents, given one parameter, a URL that points to a CSS file. I found that the file_get_contents and file functions both crash when given a URL. Both work normally when given a pathname on the local file system. As I understand it, these functions are supposed to accept a URL if the INI directive allow_url_fopen is enabled. I checked by calling ini_get; it is. In any case, the php.net description of fopen says that if that directive is disabled, "PHP will emit a warning and the fopen call will fail" -- not just hang! It appears as if there is a glaring bug in one of PHP's core functions. I'm very skeptical that that is really the problem, but I don't know what else to suspect. Any ideas? My configuration is Windows 7 Professional with SP1; Apache 2.2.17; PHP 5.2.17. For reference, here is the script I used to investigate this problem. I stepped through it with a debugger, so I didn't bother displaying results. As shown, the script works. When I comment out the second assignment to $path it should produce identical results; instead it hangs. <?php $isopen = ini_get('allow_url_fopen'); $path = "http://localhost/pdf/cert.css"; $path = "D:/htdocs/pdf/cert.css"; $contents = file($path); $contents = @file($path); $contents = file_get_contents($path); $contents = @file_get_contents($path); ?>

PFMaBiSmAd, I don't think you (or MasterACE14) understood what I'm trying to do. The point is not to assure that the passwords will be secure as long as everything is working as it should. The point is to improve the odds that the passwords will remain secure when something is not working as it should... for example, when an intruder gets unauthorized access to the document root, as happened on my client's hosted site a few weeks ago. For context, I googled "php database password security." The first four matches all mentioned the technique I described (see below). Some suggested storing credentials in the inaccessible file as code, others as data. I found nothing that pointed authoritatively to one technique or the other being more reliable and/or secure. Using .htaccess to block access to a file that is in the document space was also mentioned in several places. That is certainly easier, but again, I've found nothing to help me judge whether it is equally secure, less so, or more so. That is what I'm asking about. Here are the four references I mentioned above: http://php.net/manual/en/function.mysql-connect.php: "I recommend creating connect and cleanup functions in a separate include file. If security is a concern, locate the include file outside of your web root folder." http://www.sitepoint.com/php-security-blunders: "Place configuration files outside your Web-accessible directory. A configuration file can contain database passwords and other information that could be used by malicious users to penetrate or deface your site; never allow these files to be accessed by remote users." http://stackoverflow.com/questions/97984/how-to-secure-database-passwords-in-php: "If you're hosting on someone else's server and don't have access outside your webroot, you can always put your password and/or database connection in a file and then lock the file using a .htaccess..." http://phpsec.org/projects/guide/3.html: "Of course, one simple solution is to place all modules outside of document root, and this is a good practice. Both include and require can accept a filesystem path, so there's no need to make modules accessible via URL. It is an unnecessary risk."

"Nested loops" is the description I'm accustomed to. A foreach loop seems like a reasonable solution to me. In most cases it's the only clear and reliable way to deal with iteration over an associative array, and it's often useful with indexed arrays too. It looks to me like you have a good grasp of what you want to do and how to do it, and all you need is experience.

I'm sorry MasterACE14, I don't follow what the code is doing. It appears to me that myscript.php is simply getting the password by including another script from the same directory. That's hardly more secure than putting the password directly in myscript.php; the only additional work an intruder has to do to steal the password is look at a second script.

I can't be sure this is the only problem without watching your code run, but you start the list before the loop and end it within the loop. This is hard to see as you displayed the code, but becomes quite obvious if you indent it. Here is how it looks when indented according to my own habits. (Well, almost according to my own habits; improperly nested code can't be indented properly, which is part of the point here.) <div id="thumbs" class="navigation"> <ul class="thumbs noscript"> <?php foreach( $cck->get( 'property_listing_images' )->value as $large ) { foreach($cck->getValue( 'property_listing_images' )->value as $thumb1 ) { ?> <li> <a class="thumb" href="images/<?php echo $large->value; ?>" title="Title X"> <img src="images/<?php echo $thumb1->value; ?>" alt="Title X" /> </a> </li> </ul> <?php } } ?> </div>

I understand that the commonly used means of securely supplying a password to a script is to store it in a text file outside the document directory. The script reads the file and extracts the password. Because the password is stored outside the document directory, it is difficult for an intruder to steal. This makes sense, but it seems more complicated than necessary. Why not assign the password to a variable in an include file stored outside the document directory? The script can simply include the file instead of having to open a file, read it, and parse it. The security is the same. I've tried this technique on my development system (WAMP) and on my client's hosted test site (LAMP), and it works in both places. (In each case the directory I chose was the parent of the document root. In Windows it is the root directory of my data disk. In Linux it is a child of the account's home directory.) Am I just lucky that this is working for me? I'm puzzled that it isn't used in preference to the read-a-file technique.

Thank you again, Adam. I thought I might get a "better" answer if I approached the problem in a different way, but I'm getting persuaded that there really is no way to do this within standard browser architecture! Another possibility occurred to me -- not one I'm going to pursue now, but I wonder if it would work. Suppose the download was performed through a Java applet rather than with the standard content-type header. The applet could communicate with the script in any way that met its needs, subject to tje limitations imposed by a typical configuration of Apache. When it was done, the applet could load the next "real" page.