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

Allow syncing other properties from an IDP as it allows standard items that most OAUTH providers allow such as First Name and Last Name Should be able to map properties from IDP User Information Endpoint JSON response to Member Profile field Allow "Update local database" from multiple IDP's because if you do have multiple IDP's enabled then you would want each IDP to update the details. In theory a user account should only have 1 linked IDP - doesn't make sense to have multiple IDP's connected to a single account. Roles claims should allow mapping to groups (at least for other OAUTH or non-social IDP's)

Not a problem, thank you for your help!

OK I've just deleted the default Invision Community and I'm now able to update those settings. Still, I think there has got to be some enhancements made to Invision Community Suite regarding OAUTH settings and flexibility in synchronising other properties.

Ohh, yes I didn't create that one. I've deleted that additional standard one but there is still those other items I mentioned regarding multiple IDP's etc.

@Marc the standard one is enabled. The default Invision Community one does indeed have that setting enabled. This makes no sense to me because if you do have multiple IDP's enabled then wouldn't you want each IDP to update the details? In theory a user account should only have 1 linked IDP - doesn't make sense to have multiple IDP's connected to a single account so in that scenario these settings don't really make sense. Further I can't disable these because it's not configured (complains required fields are null). Adding in dummy values is not ideal, presumably the alternative is to modify the database directly.

In terms of other items syncing from an IDP, there should be more items configurable because there are standard items that most OAUTH providers allow such as First Name and Last Name. Should be able to map properties from IDP User Information Endpoint JSON response to Member Profile field. In any case please let me know if any other access is needed.

@Marc not a problem, I've re-instated access to Admin CP. I assume FTP isn't required just yet (I haven't updated those details)?

@Marc what is preventing updates to the local database from being selected? I've configured everything else identically and the instructions show this can be enabled. What settings would prevent this? Any plans on allowing more items to sync in version 5?

Hi, I followed the instructions and the "Update local database" cannot be selected as it states "This option cannot be chosen because the Invision Community login method is already doing this." for the remote display name and remote email address changes. Ok fine so also selecting disable "Show in account settings" because I don't want the user to have the option to make changes and I always want these details to be synchronised always. What option do I select between "Allow the member to chose what happens" or "Do nothing"? Selecting either of those options doesn't synchronise during login. Further, let's assume I wanted to synchronise some other properties provided in the token such as first name or last name. I don't see an obvious way to do this as only the userid, display name, email address and profile photo url can be specified.

Hmm ok, I might need to switch to another Identity platform as this will provide greater flexibility (and the ability to use the device code grant type if needed). I've got the All tab selected and only failures (401's) showing. So the /core/me endpoint should have the tooltip removed in that case and left on for /core/members for lastVisit and lastPost properties. As for secondary groups, might be helpful to add another API permission e.g. /core/me/secondarygroups and when enabled, allows all groups to be retrieved for the logged in user when calling /core/me endpoint otherwise the tooltip for secondary groups makes no sense as you'd need a user token to retrieve user ID from /core/me API Endpoint and then an API Key or Client Credentials token to then call /core/members/<id> just to retrieve secondary groups for that user which seems unnecessary.