Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SSO Client as a Composer package
PHP 7.2 testing revealed phpseclib code (embedded in the client) raising deprecation messages. 

Making the whole client a Composer package deals with that dependency quite elegantly, see the fork at:

The addendum at the bottom of the readme explains how to use it.
Changes were kept to a minimum, and this fork can readily replace the current 'sso-client' folder version in applications that are using Composer.

1) install.php has not been fully tested.
2) There are many refinements that could be made as part of the namespacing/refactoring, but they would cause installation issues, and doubts about this code's integrity (faithfulness to original SSO Client code)

Composer is becoming so important, I hoped this might be a useful contribution as part of migrating code to use it. If adopted by CubicleSoft, this would simply be published to from the CubicleSoft's current github repository, and people would not use the 'repositories' section redirecting to the Unicare fork.

Attached Files Thumbnail(s)
Recommended reading:

I'd rather see the specific deprecation warnings being issued by 7.2 and correct those rather than refactor the entire product. Deprecation warnings are generally easy to fix and may already be fixed upstream.

phpseclib is useful for userland crypto operations BUT they have the wrong mindset about good software development. When they switched to Composer as part of phpseclib 2.x, they also started making poor CSPRNG decisions (i.e. I don't trust the v2 CSPRNG they opted to use and neither should you).
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
Thanks for the reply and reading.

My priorities allow me to work with the implementation of namespaces and dependencies in PHP, but we all have our convictions. With so much code to manage (and suitable deployment procedures), I appreciate what has been done so far - and hope to see the underpinnings improve.

Will you please review your generator for There are lots of class resolution warnings when installing it. E.g. look at all the classes going into file TagFilter.php (there should only be the one).
Warnings can usually be ignored. They are things that could cause problems. In this case, if you attempt to use TagFilterStream, the Composer autoloader won't find it (because PHP namespaces are broken by design). However, the use-case for using TagFilterStream directly is for advanced users who have large data processing needs. Most users will use TagFilter as-is and never encounter an issue.

Also, it's not a conviction, it's knowing things about good software development. Each dependency adds complexity. When you have two SDKs side-by-side that do the same task, with one using a massive dependency tree and the other does not, the former will fail more often and probably be 10 times larger. Small, light, and fast wherever possible. Composer does none of those things.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
I guess I wasn't clear.

My reference to convictions wasn't to do with doctrines, philosophies and opinions. I was talking about how each programmer's situation causes them to weigh priorities and benefits.

Your philosophy and doctrines result in robust and lightweight products. These are certainly fantastic qualities.

Forum Jump:

Users browsing this thread: 1 Guest(s)
© CubicleSoft