Johno2518

If you believe "spinning up" a new box is required then it sounds like you don't know how containers actually work. There are a couple of methods to make an application multi-tenant. One method is to spin up container instances that service a specific tenant (customer environment). The other is that the application is natively capable of operating in multi-tenant. I would imagine that the former is being used - only - it may not be containers. It could be you're deploying directly from the CI/CD pipeline. Nevertheless, it would make sense to use containers moving forward. Invision is still providing "self-hosted" software so while it does then it should invest in modern deployment technology especially where this makes sense to use internally as well. I don't see containersing as adding no value - while no information is provided on how Invision runs it's cloud there aren't that many configuration on how it could be run efficiently and at scale. Further, the cloud plans offered are quite expensive for the value provided. If this was different then yes you'll probably find most if not all customers would be on the cloud plans (except for one caveate, currently there are only two locations offered for hosting which may not be suitable for some customers). Self-hosting will most likely be around for a long time unless Invision progresses the cloud plans quite substantially to make it worth the jump. The updates to the cloud plans have been extremely slow to say the least (I check on them from time to time).

I'm quite capable of doing this - however it would be much better if Invision were using modern methods for delivering their software.

I think there is varying definitions of traditional platforms. To me traditional is standing up infra to host the application. The modern approach is to use containers which removes the issues of what to include or not and how it's hosted. Spin up a container with required parameters and it's up and running - no need to think about which PHP version is needed, which Apache version or NGINX or whatever is needed etc. I would think this would be of significant value considering this is one reason Invision doesn't support the product on Windows/IIS - understandable you don't want to support a myriad of different platforms and configurations which is one thing containers address. I'd also think this add's a ton of value to the cloud offering. When you say "vision of the platform" - part of that is how to modernise the deployment and upgrade/rollback experience and it would be good to know what options have been considered and why certain things have been ruled out because it gives us insight into what Invision is thinking about it's product and services.

What are the show stoppers or considerations for not using container images?

What are the show stoppers?

I would think Invision should move to Docker Container images - I would hope this is already being used by the Cloud offering. If not, I think Invision needs to re-consider how they are packaging new versions because zip files haven't been the standard for web application deployments for a long time. Containers remove all those issues you've mentioned and mean you don't actually need to worry about upgrading files etc. - the only upgrade will be to the database schema if anything.

In moving forward, Invision should release a Docker Container image (via a registry of course) in addition to or instead of zip files. I would imagine the preference would be for a Linux container only. This keeps everything simple and consistent. If add-ons are required then they can be downloaded and "installed" to persistent storage attached to the container or someone can build ontop of the official release. I would think this is the approach Invision have taken for deployment/maintenance of the Cloud offering and so it would simplify and align the classic offering.

Not a problem, I got it sorted. I created a test member account setting it with a password. Setting the "members_pass_hash" and "members_pass_salt" fields to null for the test member in the core_members table resulted in the AdminCP showing "Set Password" as the option. The Security and Privacy section now requests Sign In using the IDP to continue. Everything now as if the user had joined using the IDP login.

There should also be a way to clear passwords for local accounts that have been migrated to an IDP.

@Marc thanks for confirming! The problem here is converting from a local IPS account to using an IDP only which makes the password irrelevant for members. I can understand for admins having both is a must in case of configuration issues (or just having local account only for break glass scenarios). I assume having the ability to "Clear Passwords" would be a feature request. In terms of doing that now, I assume the only way is to run a DB query. Are there any gotcha's I need to be aware of or is it simply a case of checking a new user account with existing accounts and see what the difference is (i.e. is it just a cleared password field)?

@TDBF I wasn't sure if that actually cleared the password, however, it also emails the users which is not something I wanted trigger.

@Marc is there a way to clear the password of user accounts in the AdminCP? I haven't seen anything in there.

NOTE: This is only visible for existing users that then login with the OAUTH IDP (linking the IPS account with the IDP account). A new user logging in does not see the highlighted section, they just see the Sign In button for re-authentication as shown below. Presumably this requires clearing the password (AdminCP shows a "Set Password" button for a new user) but I don't see any obvious way of doing so via AdminCP.

Hi, Does anyone know how to remove the section highlighted in green? Since I'm only allowing an OAUTH IDP login, entering a password is not necessary? Thanks