Jump to content
Latest News: (loading..)

superfrank

Members
  • Content count

    32
  • Joined

  • Last visited

Profile Information

  • Real Name
    Frank
  • Location
    NL
  • Website

Recent Profile Visitors

3,252 profile views
  1. To be honest, I would be surprised. For example, I can imagine BS now having an extra column for an article number by default, but who on earth (besides me) needs THREE extra columns for three different kinds of article numbers...? In 2.2MS2 (a version with an incredible number of add-ons and variations of add-ons) I hardly found contributions which were suitable out-of-the-box. I always had to alter them, or at least debug. Actually, I think only my last found Ultimate SEO doesn't need any additional work I think maybe you guys are underestimating what I am looking for. But okay, maybe I am the one underestimating and BS Edge is better than I think. Better do a test install of BS Edge and look around a bit. I think the ridiculously spacious layout and all the huge font sizes are minor detail and the least of a problem I promise I will try BS Edge! But first: Yes, Recreate Session is enabled and disabling it solves the problem (the osCsid stays, but logging in is then possible). But still - when using NONSSL this is no problem, only when using SSL. The same with the persistent osCsid in the URL, this only happens in SSL. I have tried to change the cookie paths in configure.php for a test shop running in a subdirectory (similar to "catalog") but no difference. Further all settings are like stated in my first post. I cannot see anything else possibly wrong. Web shop's cache is disabled and always has been. I suppose you are talking about WEB SHOP cache. Anyway, I am clearing BROWSER cache/history/cookies all the time.
  2. Jack, Phil, thanks for the replies, and thanks for talking sense. I understand I am one of the very few still using 2.2MS2. I also understand that this implies I am kind of on my own. I was just hoping for some long-time-osC-veteran who knows this version inside out, who would be able to answer the questions in my first post and shine some light. Thanks for you input. @Jack: You are right, the solution counts, not the method. And yes, using rewritten URLs is only a benefit. So I have installed Ultimate SEO 2.2d-15. I had to disable the line "Options +FollowSymLinks" to bypass error 404 trouble, but now the rewriting works. Compliments and thanks for this well-written, well-working and remarkably well-documented add-on. But guess what, the osCsid and login trouble as described in my first post still exists: the osCsid stays in the URL forever, and logging in is not possible. That's not as expected, right? The mystery remains... @Phil: ☀ PHP 7: Yeah, you have a very valid point. At some point there is no way around it and the webshop must be PHP7 compatible, regardless what osC version I am using. ☀ Heavily modified: I don't mean changing some colors I mean adding serious functionality, involving changes in the code as well as in the database. Some examples, just shaking them out of my sleeve: - Turn off the web shop in the admin section. Either completely or just disabling the actual buying procedures, while keeping all other functions. - Invoice generator, contrary to ORDER, since an order is not necessarily an actual buy. Functionality includes for example flexible numbering and merging with other shops. - Additional product info fields, like shipping factors and multiple article numbers, for example article number for the shop, manufacturers catalog number, EAN number. - Product attributes, contrary to options at additional cost, for example the same article in color red or blue, size small or large, obviously with separate stock count. - Customized shipping costs, like multiple flat rates depending on size and weight and optional registered mail. - Multiple images for products, zoom function on those images, image check (pixel size, file size, naming) - SEO related things, like titles, metatags, image alt tags, descriptions - some of them rotating on a daily basis. And the list goes on... Then some less important functions or just plain cosmetics, like a login box, more additional info boxes, hide/unhide whole categories, HTML email editor, gift wrap option, inc/ex VAT conversion at input, multiple configurable display options, etc. And yes, I have changed some colors too Some of these modifications are based upon existing add-ons but mostly altered anyway to suit my needs and wishes, some are written from scratch. I guess you understand that here is not a case of just installing Edge and exporting/importing the database. I do not have an external list of all modifications I did, but inside the code everything is documented (comments about what and why). If I do a grep search on the server or an extended search with HomeSite, I will find everything that starts with "// fff - " ☀ Responsive design: This will make some people shake their heads, and no offense and all respect to the creators of the new version, but this would be the last reason to upgrade to Edge. I have some unusual ideas about smartphones, but let's not get into that Besides, "responsive design" usually means pleasing the owners of 144 different kinds of mobile devices and meanwhile upsetting everybody with a horizontal desktop screen or even a laptop computer. For example: the responsive design of the current default BS Edge barely fits 9 categories on my 24 inch desktop screen, instead of the 24 categories with my 2.2MS2 shop. And I need to scroll vertically to see all info about a product and find the buy button. And the title eats up 20% of the vertical space. Etc. All because of unnecessary spacing and sizing aiming at mobile devices. Excuse me, but I don't think that's the right response. And yes, I know what are style sheets, but I think you know what I mean. Yes, without responsive design I am loosing customers. But I have some unusual ideas about business, too. I rather have my customers enjoy the sea, sand and sun while they are on the beach then buying in my shop. In my eyes that's something good, not bad. ☀ Forking: Yes, I guess I have been forking osC 2.2MS2. It was a great idea at the time, and worked well for a looooong time, but maybe now not very good. But what can I do? I just don't want to be dependant on (waiting for) 'official updates' and only apply full/automated/compatible add-ons. ☀ Try Bootstrap: I still think going from Bootstrap Edge to what I want will be a huge pain, even including accepting a slightly different appearance and behavior (I totally agree with that!). Looking at it a bit deeper did not make that less, maybe on the contrary. But okay, fair enough, I will give it a try. @All: I understand there are two problems for me to solve: 1. The first and urgent one is to have the shop fully SSL-enabled and working. This could be done by forcing the use of cookies or hard-coding the $add_session_id to false. Probably forcing cookies would then be better option (right?). Or of course fixing the problem, either by myself or with some help of some veteran giving me a golden tip. 2. Eventually I would have to be ready for PHP7, either by upgrading to osC BS Edge or by fixing code within the existing shop. Either one will be quite a job, but there is still some time. Thanks for your input.
  3. As far as I know, 2.2MS2 was the first version doing it the smart way: adding an osCsid once and dropping it the next link (if cookies are enabled/possible on the visitor's end). There was no 'fix', it was just a matter of having the right settings. And that is my headache here: if it behaves like that on HTTP, why not on HTTPS...? Yes, I saw some things about that, including the hack of Ultimate SEO URL's modification to ~/includes/functions/html_output.php - changing the line $add_session_id = true setting true to false. Installing Ultimate SEO surely is an option, and nice URLs are not a bad idea anyway ;-) But looking at it beforehand, I have the impression it would kill the osCsid always, instead of only the following links. In fact, I could change true to false even without installing Ultimate SEO, since that piece of code is in the function tep_href_link already. But both methods wouldn't be exactly how I want it: I want a backup plan in case the visitor has cookies disabled, just like with HTTP. I think the problem/solution lays somewhere in that function as defined in html_output.php or rather in extensions of it (some function in sessions.php). Maybe some bug, forgotten code to cover SSL, or something like that. But I don't see/understand where and how.
  4. A Trabant with four wheels (without flats) still gets you where you wanna be. ;-)
  5. A vanilla 2.2ms2 on non-SSL versus SSL is doing the same...
  6. I am sorry. Once again, thank you for your concerns and solutions, but for me they are not solutions. And the discussion "to upgrade or not to upgrade, that's the question" is very interesting, but really off-topic. My new shop might be using BS Edge. But my existing shop just has a few questions. For those who want to help, see above.
  7. Yes, I have seen and read that topic (before posting mine). As said, my 'better' solution would be to force cookies, but that would be "better", not "good". How to fix that flat tyre...
  8. My shop survived PHP 4 to 5, the funny 5.4, all the minor stuff like register_globals, register_long_arrays, not to mention all the deprecated functions and so on. So to answer your question: yes, I think it will survive PHP 7 - not without any battle, but it will. Besides, my host only upgrades to v7 when/if I want. Once again: thank all of you for your concerns, but really, I just have a flat tyre. I want to fix my flat tyre, not buy a new car. Please tell me how to fix my flat, not where to buy a car. I had already found that elsewhere on the forum and tried it, but it doesn't do the job. In fact it makes it kind of worse: now logging in doesn't even work when deleting the osCsid from the URL. The same for variations without "www". I think that added dot is only the case for later versions.
  9. Thanks for the idea, but really, with "very heavily modified" I really mean "very heavily modified" in huge bold capitals - you would be surprised ;-) Of course I have considered upgrading, for more than one reason, but that would not be the way to go, trust me. What is killing me: in non-SSL mode things work the way I want. Where is that piece of code that makes the osCsid disappear and allow login etc. and what is the difference when using SSL? I would say it is dead simple - but apparently I am missing something. Right now I would say: okay, force cookie use - cookies are kind of 'normal' and I can live with loosing a couple of customers (IF that is the only 'cost'). But that would be last resort, I am not ready for that (yet). I am hoping for some guidance into the right direction.
  10. I have a very heavily modified install of osC 2.2 MS2 - 060817. Recently I changed the entire shop to use HTTPS. To achieve this, I changed the two configure.php files - the one for the shop and the one for the administration section. The relevant part of the shop's configure.php is now: define('HTTP_SERVER', 'https://www.my*web*shop.nl'); // eg, http://localhost - should not be empty for productive servers define('HTTPS_SERVER', 'https://www.my*web*shop.nl'); // eg, https://localhost - should not be empty for productive servers define('ENABLE_SSL', true); // secure webserver for checkout procedure? define('HTTP_COOKIE_DOMAIN', 'www.my*web*shop.nl'); define('HTTPS_COOKIE_DOMAIN', 'www.my*web*shop.nl'); define('HTTP_COOKIE_PATH', '/'); define('HTTPS_COOKIE_PATH', '/'); (...) define('STORE_SESSIONS', 'mysql'); // leave empty '' for default handler or set to 'mysql' Administration > Configure > Sessions is this: Session Directory /usr/local/sites/*******/tmp/ Force Cookie Use False Check SSL Session ID False Check User Agent False Check IP Address False Prevent Spider Sessions True Recreate Session True Now a problem occurs. The osCsid stays in the URL all the time (not really recommended) and logging in is not possible. If I manually remove the osCsid variable form the URL I can login, but obviously this is not something I can expect my customers to do. I found two possible solutions, by changing the settings in Configure > Sessions: 1. Set the value for "Force Cookie Use" to TRUE. Now the osCsid simply never appears in the URL (is that good or bad?) and visitors must have cookies enabled (workable, but not perfect). or 2. Set the value for "Recreate Session" to FALSE. The osCsid variable keeps on appearing in the URL every click (not really good), but at least the visitor can log in. But these are not really the solutions I want. While the site was completely NON-SSL, the osCsid variable showed up only once in the URL, and disappeared the next click. I do not force visitors to use cookies. And I recreate the session. That's how I like it to be. My question: Why is the behavior different when using SSL? Or rather: what should I do/change so that - visitors can log in - the osCsid variable appears only once in the URL - Force cookie use can be FALSE - Recreate Session can be TRUE just like it used to be when the shop was NONSSL. Or if I am asking something impossible, what are the (serious) down sides to Force Cookie Use : True and Recreate Session : False? For example, I read elsewhere on the forum some vague rumors that some payment processors need an osCsid or that not recreating the session could be a security issue. Btw, the shop is so heavily modified that a complete upgrade to osC 2.3.4 BS Edge or so is not an option.
  11. So I guess I am right with my conclusion that things are still the same like before June 30. I have the same thinking as you - I want to test live and be 100% sure it works, but I don't want to check every day. Instead I guess we will have to check that forum every day. Oh, and maybe that roadmap publication too. Great ;-) I do not have a 'copy' web shop to run tests in. Nor I think it's a good idea to use the sandbox in a live shop (test and real orders could be mixed). Anyway, thanks for pointing that forum/topic out to me. As you suggested, I have added a post.
  12. And so I have just tested. Things are working fine. BUT... I just noticed an update on the PayPal roadmap about this (see the red update text on https://www.paypal-knowledge.com/infocenter/index?page=content&widgetview=true&id=FAQ1913&viewlocale=en_US ) "While we are allowing for these security updates to be made after June 30, 2017, we continue to recommend that you prioritize the changes and updated protocols specified by the PCI Council so you are best positioned to protect your customers from security and fraud-related issues." "While we are allowing for these security updates to be made after June 30" - do I understand well that PCI and PayPal have postponed the deadline? And that PayPal has NOT changed anything yet? If so, what's the new deadline?
  13. You are a gift from heaven, Harald the Legend. Thank you for your expert replies, giving me trust and peace of mind. Maybe a sandbox test would be better than theoretical talk, but I am not to keen on it with a live shop and I don't have a copy-shop to test with. Anyway, I have the feeling things will be fine after June 30. Thanks. I have passed the info to the Dutch osC community where I asked the same questions.
  14. Thank you for the good - and fast news. Yes, I think "legacy" is the right word. It needed some fixes along the way, but still working like a charm, nonetheless :) I am not sure if this is off-topic or not, but maybe you (or anybody) can help me with two other PayPal security update issues as well. To be clear once again: for the standard, unmodified, built-in paypal module of 2.2MS2: - IPN Verification Postback to HTTPS I understand HTTPS should be used *IF* IPN is being used. However, the standard module does not feature "IPN" (it would involve an add-on). So that means I do not need to change anything. Is this correct? - Merchant API Certificate Credentials Upgrade A similar situation: I understand this is only if "Express Checkout" is being used. Which is not the case with the standard built-in PayPal module. So no need to change anything. Correct?
  15. I suppose you mean 'your' PayPal App (currently 5.010) meant for osCommerce Online Merchant v2.3 ... I am using osC 2.2 MS2 - 060817 (yes really) and its standard built-in PayPal module. The osC install is heavily modified, but not the PayPal part - no add-ons, no modifications. The only reference to PayPal I can find is in catalog/includes/modules/payment/paypal.php on line #32: $this->form_action_url = 'https://secure.paypal.com/cgi-bin/webscr'; but I have no idea if after merging this is resulting in a GET or POST. Do I need to change anything in the code? If so, where?
×