OmniPay VS ua-parser-js

Seems like it’s unrelated to OMNY. Looks like it’s just a gateway for payment https://omnipay.thephpleague.com/. Someone more dev-minded might be able to explain more, but might be worth calling your card company

check out https://omnipay.thephpleague.com/ a very extensive library supporting many multiple popular gateways like Stripe. There are many Laravel examples on github for its use.

> If their site is already Wordpress and they ask you to fix it, then your job is to fix their Wordpress site. Where is the shame and disrespect in that?

None. I just finished up such a contract myself earlier this month. I was speaking of building new sites from scratch.

> I agree about the spammy notifications and PHP code snippets. But sometimes code snippets can save time.

Put code in code files, under version control. Not in the database. Not in a blob field that gets eval()ed and is editable by users. This is sane web dev 101.

> I'd be interested to hear what good replacements there are for Wordpress+WooCommerce?

Drupal 7 + Drupal Commerce was very nice back in the day. I don't know the current state of Commerce under Drupal 9 but it's what I'd start looking at first if someone wanted me to build them a store from the ground up. Magento is still around, though I've heard that its code is incomprehensible. And if you're not afraid to take the thin framework or frameworkless route, the Omnipay library [1] combined with standard CRUD for the products should get you pretty far.

1: https://omnipay.thephpleague.com

I didn't know about this project for payment gateways from the article: https://github.com/thephpleague/omnipay

Just look at all the big companies doing it

https://faisalman.github.io/ua-parser-js/

This project is backed under MIT License, special shout out to project UA-Parser, as liguard uses a piece of its source-code.

With NPM, what's actually published is not what's in the git repo, so it's harder to inspect/review vulnerabilities or hijacking. With composer, what's in git _is_ what composer pulls (with the exception of rules in .gitattributes to exclude files etc), making it much easier to trace. One such example: https://github.com/faisalman/ua-parser-js/issues/536

Composer packages are vendor namespaced, so hijacking an abandoned package is not possible (and it is with NPM), some examples like https://www.theregister.com/2021/08/10/github_npm_package/

Sure, I suppose in theory it could happen with other ecosystems, but for some reason it doesn't. It sure seems to just keep happening in NPM though.

From the other side, npm package may be hijacked(as it happened recently for ua-parser-js and to other packages earlier). To mitigate that, I don't know, probably, subscribing to some security digest would be the most helpful.

On Oct. 22, 2021, developers of a very common NPM package, ua-parser-js, discovered that some attackers uploaded a compromised version of the package containing malware for Linux and Windows, and were capable of stealing data (at least passwords and cookies from the browser).

Since Neovim 0.5 release (which has full Lua support) I see more and more amazing Lua plugins being developed, and I think this trend will likely to continue. But I recently got more concerned about security risks associated with the way Neovim plugins being installed and used (especially after seeing recent compromises like ua-parser-js or coa). Installing typical Neovim plugin is basically downloading and executing random code from the internet on your machine with your user privileges, so hijacked or deliberately malicious plugin could potentially do a lot of damage (like stealing keys/passwords, installing keylogger or just rm -rf / for fun).

thread about compromise https://github.com/faisalman/ua-parser-js/issues/536