• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral


Profile Information

  • Real Name
    Richard Bentley
  1. I have posted an update to the contribution (dated 25 Sept. 2007) - this should answer your questions re which version to use. ref. regards Rich.
  2. I'm not at all familiar with this "User Tracking" contribution but judging from the fix that you posted up, the more correct way of fixing this (indeed, the way the contribution should have been written in the first place) would be to find all instances of where the variables 'time' and 'viewsession' are used and replace those references with $_GET['time'] and $_GET['viewsession'] respectively. Of course, it is possible the these variables are also accessed from other files that may be brought into the 'user_tracking.php' file. In which case, you need to alter those references too. Then again, if this is not the case then the change is restricted to just the one file. Hope this helps Rich.
  3. At the risk of sounding flippant, if the RG patch doesn't work, it is probably because you've not installed it correctly. The patch DOES work - honest! Did you read ALL the installation instructions? Despite the notice at the top of the instructions saying "READ ALL OF THIS...", it is AMAZING how many people don't bother and then come unstuck and wonder why. Also, register globals has NOTHING to do with the Apache web server or any .htaccess files that you may have. Register Globals is a PHP issue; Apache knows nothing about such things. So, take out any ref. to register globals from the .htaccess file. Oh, hang on - this is not true! You probably CAN set the PHP RG setting from with an apache config block :-) I have never used this idea of sticking a php.ini file in the www directory. It sounds very strange to me, but I have heard it before so I can only assume it works (or not, as the case may be!). Rich.
  4. Why would you want to do this? $_* is the preferred way of referencing the global arrays but there's nothing actually wrong with with using the (old) $HTTP_* syntax. I could be wrong, but I think $HTTP_* will be deprecated and eventually removed from PHP, but if you don't have a problem then I would leave it alone; there is no advantage in changing it and the scope for messing something up is quite high.
  5. No, you've probably not done anything wrong. I put this comment in the contribution's instructions because at the time I made the contribution, I wasn't convinced that the session handling would still work if you had RG enabled at the same time as having the patch installed. I'm still not sure, and haven't looked at it further to convince myself one way or the other. But to be on the safe side, I would not run with this patch installed with RG enabled; if you do, you might mess up the session handling. There's no point in doing this anyway (as I am sure you are already aware). Rich.
  6. If that's what you think the problem is then I suggest you install the register globals contribution last and use the step-by-step instructions (rather than the pre-patched files) for the files that have already been modified by your other contributions. Rich.
  7. It may be useful to know that the register globals contribution includes a patch for easy populate :-) Rich
  8. That's because the version of the register globals contribution that you are looking at is rather old now and should not be used with the latest version of OSC. It was created from the original contribution that I wrote which you can find here...,2097 This (original) register globals contribution has been kept up to date and can be used with the latest OSC versions. It also includes line-by-line instructions in case you need that so the diff that you've been doing has actually already been done for you :-) Rich.
  9. I know this question was posted some time ago, but I have a spare minute so here goes... To answer your point re "display" vs "real" order number, the OSC database can only use the "real" (ie, 1, 2, 3...) order number. It simply can not take an arbitrary (random) order number and somehow relate this to an order record in the database. Well, it COULD, but to do this requires a lot of changes to the code and is basically too complicated, generally unmanageable, expensive (in terms of database access) and (as it turns out) unnecessary. In order to keep the database indexing simple, the scrambled order number contribution does not change the database order number format at all. It is EXACTLY the same as the base OSC. This is a GOOD thing! However, the requirement is to present a "random" order number to the customer. Therefore, the OSC code (with this contribution) uses the "real" order number as normal and ONLY converts it to a "display" (or scrambled) order number when it needs to present the order number to the customer (whether this be on the web page or in an email). Because the user only knows about the "display" version of the order number, we also need the ability to convert this back to a "real" order number so that when a customer sends us an email to complain that we've sent them the wrong thing, we can put the "display" order number into the order search box (in the admin pages), convert it to a "real" order number and access the appropriate database record. The important thing to remember is that the user ONLY sees the "display" order number and the OSC code can only use (and only NEEDS to use) the "real" order number. The "display" order number is not stored anywhere in the database; it is always generated on the fly from the "real" number. This answers your other point. That is, by always generating the "display" order number on the fly like this, there is no need to store it anywhere and therefore no need to modify the database from its standard configuration. By using the "randomise" and "derandomise" functions (defined in the contribution), we can always relate one to the other. This keeps things much simpler. Rich.
  10. For what it's worth, I would like to say that SECPay have been extremely helpful in the past in helping to solve integration problems. Their docs are very good too. I made some changes to the SECPay module I use some time ago to improve the security and fix some bugs and the techies at SECPay helped me in particular to nail down a particularly frustrating problem. So I would suggest that if you want to implement this new functionality then don't be afraid to ask SECPay if there's anything that's not clear. I was thinking of adding this (3D-Secure) too, but am very busy and am holding off until its use is more widespread. Rich.
  11. If you know your PHP then you can take a look at the contribution code and check for yourself if it will work with register globals off. If you don't know your PHP then I'm afraid the short answer is no, you can't easily tell. The only thing you can do if you're not sufficiently technically savvy is to i) contact the contribution author, ii) check this forum to see if anyone has posted up any info that may help, iii) try the contribution anyway and see if it looks like it works (but this can be dangerous, because your testing may make you think it works correctly when in fact it doesn't), iv) Ask (which is what you're doing, and not really getting anywhere), and ....errrr ...that's about it I'm afraid. As I've pointed out before, it's basically down to sloppy coding. There is absolutely NO EXCUSE for writing a contribution that does not work with register globals off. Many contributions (and pretty much all of the really popular ones) have been updated regularly enough over the past couple of years for this issue to be addressed, but in many cases, the contribution authors choose to ignore the problem. And for me, the "OSC works with RG on as standard so why should the contributions work differently" excuse does not wash at all - RG is an issue for many many people and the contributions should reflect this. It's lazy and sloppy; pure and simple. Maybe you could ask the contribution webpage maintainers to add an extra tick box to the contribution upload system so authors can indicate whether or not the contribution is "RG off" compliant. This could then be displayed with each contribution (and searched for!) and you would then know in a standard way which contributions will work. This would also encourage authors to address this problem. But back to your problem, no I'm afraid other than what I've just suggested, there is no magic way of knowing which contributions are written well (and work with RG off) and which are not. One last thing - the register globals contribution does include a fix for easy populate, but that's the only other contribution it does address (and I'm still not certain it's correct). Rich.
  12. Put up version 1.5 of the register globals patch. This will work for the 17/08/2006 release of OSC regards, Rich.
  13. If you set it up correctly, yes, it will work with any version of EP. Rich.
  14. I didn't even realise there was a new version of OSC. I'll look at it and update the register globals contribution accordingly. It will probably take me a few days to get round to it though. Rich.
  15. Came across this and thought I would impart some experience which may (or may not) help someone out there. There is a problem with the way the SECPay module handles the callback. When the callback occurs, the OSC code uses a http 301 redirection to cause the browser to bring up the "order complete" page. However, this does not always work correctly; it depends on whether you have SSL enabled in the callback (you should ALWAYS have SSL enabled - I'm very surprised SECPay even provide an option not to), and may also be affected by some of the other options that you can specify to SECPay. Some time ago, I spent many hours trying to work out what was happening. With the generous help of the SECPay crew, I managed to work out that the problem was the 301 redirection; it does not always work! Instead you must initiate a http page redirection. This involves creating a small html page with the redirection instruction in it (sorry - I can't remember the exact details/syntax and I can't be bothered to look it up right now, but it's the same mechanism that is used to cause periodic refreshes of a web page so I'm sure you can find it on google). The reason the 301 redirection does not work is not at all obvious if you don't understand how the SECPay transaction works, but basically it is because when the client browser is within the transaction phase, the data flow is from the client browser through SECPay and then to OSC. Therefore, some of the OSC code is running in the "context" (not really the correct word) of SECPay and NOT the client; the SECPay site is operating as a sort-of proxy (again, not quite correct, but it will do for this explanation). In order to fix this, you need to hack OSC to change the 301 redirection into a http redirection. I shall leave this as an exercise to the reader to work out; it's not a 2 minute job to do though because other bits of OSC still use the 301. There may well be other problems with the SECPay module in OSC (OK, I know that there are - it doesn't check the callback integrity correctly, for example) but this is one of the fundamental faults that can stop it working. Oh, and no - SECPay does not use cookies. Hope this helps someone. regards Rich.