I have included the PHP Stripe lib version 4.4.0 into my Slim Framework setup version 2.4.2. PHP version 5.4.16.
I autoload in the library using require ("../vendor/autoload.php");
However when I call:
\Stripe::setApiKey($this->stripeKey);
$customer = \Stripe\Customer::create(array(
'email' => $email,
'card' => $token
));
I get the error "Class 'Stripe' not found" I think its to do with the Slim Framework not integrating with Stripe.
I have downloaded https://github.com/collegeman/slim-common which is a Slim project that has Stripe integrated and that works ok, but I am looking to update the Stripe library to 4.4.0 (its latest version)
Update
When I remove "namespace Stripe;" from the stripe/stripe-php/lib/Stripe.php it proceeds to say "Class 'Stripe\Stripe' not found in /vendor/stripe/stripe-php/lib/ApiResource.php on line 16"
Looking at the documentation usage looks like the following:
\Stripe\Stripe::setApiKey($this->stripeKey);
I think this is a PHP version issue.
The recent versions of Stripe require PHP >= 5.6.0, see the documentation here on GitHub.
A few months ago, I attempted to install a slightly earlier version of Stripe (whatever was newest then) with PHP 5.4.16 and it generated the same exact error message.
I think you may need to upgrade PHP. Alternatively, you could try using an older version of Stripe that supports PHP 5.4. However this would not be a good solution; PHP 5.4 has reached end-of-life as of September 2015, a long time ago, and as a result may have a long list of concerns associated with it. Back when I was running PHP 5.4, over the past few years, I have run into a long list of problems with it, including it not working with newer software packages, and not supporting modern best-practices with respect to cryptography and other security measures. Even if you manage to get Stripe working here, you may run into other problems down the line, perhaps with Stripe, or perhaps with other software packages, security, etc.
At a bare minimum I recommend upgrading to 5.6, but as that version has already reached end-of-life too (December 2018) an actively-supported version such as 7.3 or greater would be better. I upgraded to 7.4 which is supported through November 2022 and will likely be supported for Stripe much longer than that, and it fixed the problem here, as well as a variety of other unrelated problems I had been having, although I did need to rewrite quite a lot of code in order to do the migration.
Related
We are still running Magento community version 2.3.4x.
We are upgrading since 4 months to current version, there were many plug-ins not compatible and so on.
Now we are about 2-3 weeks before we can fully switch.
On 11. of Oct. Adobe released:
Security update available for Adobe Commerce | APSB22-48
https://helpx.adobe.com/security/products/magento/apsb22-48.html
But our version of out of service since one month.
So we can not switch now, and there is also no patch.
Adobe Commerce 2.4.5 and earlier versions
What can we do until then?
I know this is not an adequate question here, but since It will probably affect 60% of all Shop worldwide, it's necessary to ask this here.
Maybe try this: https://github.com/EmicoEcommerce/Magento-APSB22-48-Security-Patches
This repository contains Magento 2 Patch Files for the recently found security issues on 12-10-2022. The patch files aim to fix the CVE-2022-35698 and CVE-2022-35689 vulnerabilities.
I'm downgrading node.js from v7.7.4 to v0.10.48 because I'm on a CentOS 6.5 server and apparently v0.10.48 is the latest it can handle. Are there issues with going backwards like this?
It should work
There are no issues in way that it will work just as well as it did when it was the current version.
But...
There will be issues with the compatibility of modules on npm. Many of the modules may not work. That is partially because Node v0.10 uses V8 v3.14 (for comparison the current Node versions use V8 v5.x) so a lot of modern JavaScript syntax doesn't work there.
Syntax
For details of what syntax works and what doesn't see:
http://node.green/
For example you will not be able to use a simple arrow functions:
const add1 = x => x + 1;
or even the const keyword for that matter. You will miss a lot of syntax that we now take for granted even on the frontend. Remember that io.js was forked from Node v0.12 mainly because it used such an outdated version of V8 - and it was literally years ago and was about a newer and much modern version than the one you want to use.
Core API
Also the core modules changed during that time changed a lot - compare:
https://nodejs.org/dist/latest-v0.10.x/docs/api/
https://nodejs.org/dist/latest-v7.x/docs/api/
Modules
Because current versions of Node support newer language syntax and have improved core API, a lot of the modules on npm will not work correctly or at all. Make sure that whatever module you use still supports Node v0.10 or use an old version that did support it. You may need to use shrinkwrap to downgrade a lot of sub-dependencies because even if you use an old version of a module that used to work on Node v0.10, it may still load the latest versions of its dependencies that don't work any more.
Security
Also there will be potential issues with bugs and vulnerabilities that will not get fixed. The v0.10 version manitenance ended on 2016-10-31 and the status of this version is currently: End-of-Life. The oldest version that is still maintained today (as of May, 2017) is 4.x.
See:
https://github.com/nodejs/LTS
We have SAP Hybris Commerce version 5.1.1 with custom extensions installed. Now we need to upgrade it to newest version 6.2.
My question is: Can we upgrade it to 6.2 and skip all versions between 5.1 and 6.2? Or must it be done by upgrading to 5.2, then to 5.3 and so on?
Yep - 5.1.1 to 6.2 ought to work (I've been working on a project that's done exactly this).
You will probably have to make some changes - watch out for any customisations you've made - it might be worth reading through the release docs to have an idea of what's changed - off the top of my head the structure of add ons is one area that's a bit different between 5.1 and 6.2, but otherwise things should work OK in theory.
Yes you can directly update to 6.2.
It's important to regulary update your hybris version. You should not have so much gap with current version. Indeed it become tougher to migrate your custom code.
Upgrading each minor version in a row is totally useless most of the time. Only do this if you have issues you can't solve while migrating to the target version.
You should take a look at this migration documentation and this guide (it can be used even if it doesn't match your version).
Note that some stuff like promotion are totally different in hybris 6 so you can expect some trouble to migrate everything. Take care of your extensions generated with old template also.
5.5.1 introduces JDK8 and Spring 4, I would not underestimate this change! Depending on the size of your project I would first go for 5.5.1. Also notice the MySQL change for 6.2 (5.6). Don't forget to declare deployment tables in your items.xml. Search for "third-party compatibility" and "release notes" on the wiki. Also try shifting to the backoffice since the hMC is marked as deprecated.
Yes you can migrate directly 6.2.
The time and difficulty depends on your custom code (and how much it respects good practices : naming conventions, usage of service, architecture respect...etc)
You might also consider that HMC is deprecated in 6.2
Meteor is typically behind in Node.js version because it is a framework that uses its own bundled version of Node.js, and its APIs and features are built to rely on that version of Node.js.
I'm sure that in many cases upgrading Node.js poses no problem.
As an example, Meteor 2.10 at time of writing ships with Node.js 14. But we're already on Node.js 19.
Is there a way to tell Meteor (f.e. with the meteor cli, or some meteor package) to use newer versions of Node.js (and npm)?
Meteor 1.4 now supports Node 4.4.7!
See release notes
To upgrade to Meteor 1.4:
Go to the root of your project's directory
meteor update
Meteor does not support NodeJS 4+ as of now. The discussion is available in https://github.com/meteor/meteor/issues/5124
The latest update to the thread on April 29 is:
Guys, relax. The difference between Node version 4, 5 and 6 are relatively minor, and so if Meteor can support one, it can and will support all others. Ben created PRs for every currently active and supported Node version, but the fundamental part of the work is about making Meteor work with any (recent, non-legacy) Node version, and from there basically everyone should be able to freely select whichever one fits their goals and intentions best (i.e. 4.x if you don't care for bleeding edge Node, 6.x if you do; 5.x is not going to stick around for very long as it's not an LTS version).
So come and check out and help with the PRs if you're interested and
you can, but if not, just rest assured this is being worked on and
prioritized appropriately and I'm pretty sure Ben (and/or others
working on this) will keep everyone posted on any meaningful progress.
Today, our Enterprise Architect mentioned that a recent vulnerability was discovered in the JRE 1.7. I found an article the JRE 1.7 vulnerability recommending disabling Java.
I am running JDK 1.5 and 1.6 at work (like many organizations, we're not on the latest of technologies), so no problems there.
At home I am doing development with Java SE 7u6. I'm playing with Grails, Spring Security, trying to keep learning.
I have already gone and disabled the Java Plug-in in all my browsers on my home development machine. However, does anyone know if my home dev machine is still vulnerable by virtue of having the JDK 7 installed? I did find this article on US-CERT declaring the vulnerability notice: Oracle Java JRE 1.7 Expression.execute() fails to restrict access to privileged code.
It sounded like as long as the browser is not able to run Applets, I should be fine (it should not with the Java Plug-in disabled). However, what about Java Web Start/JNLP? Could that get invoked? That's the only other thing I could think of, other than Applets, that might be of concern.
Just wondering if I need to go through the efforts of uninstalling my Java SE 7 and dropping back to a JDK6.
What have others done upon learning of this security issue with JRE 1.7?
The details of the latest vulnerability have not been made public. However, my understanding is that it only affects Java browser plugins. The recommended mitigation is to disable the Java browser plugins. No mention is made of non-plugin Java, so I think it is safe to assume that your dev machine is not vulnerable simply by virtue of having Java 7 installed.
However, what about Java Web Start/JNLP? Could that get invoked?
I don't think so. I think it is safe to assume that the people who found the problem would have thought of that potential attack vector. (But simple common sense says that you wouldn't want to be launching random JNLP programs in the first place ...)
I understand it as if you have to visit a malicious site to become infected. So no, you are not at risk simply by virtue of having Java 7 installed in your browser.
Some useful links:
US-CERT link which explains the vulnerability:
http://www.kb.cert.org/vuls/id/636312
Oracle link to their Security Alerts (not just Java, but also including Java):
http://www.oracle.com/technetwork/topics/security/alerts-086861.html
As of writing (30 Aug 2012) I cannot see that Oracle has yet issued an alert for this. I can't really figure out if they only issue such alerts AFTER a patch has been created. According to US-CERT site Oracle was officially alerted on 29 Aug 2012 but they may already have known about it because blog reports about the vulnerability started a few days before the 29th.
What you can read on the Oracle site is that the next planned "Java SE Critical Patch Update" is on 16 October 2012. Surely they won't wait for that but release an out-of-band patch for this vulnerability asap. (they've done so before)