Justin Lex-Hammarskjöld

Hi Marc, thanks for your input on this. As a developer, I am skeptical about the challenges of adding an auto_increment primary key column to these tables, but I'll take your word for it and avoid this path. We are aware of the /core/members POST endpoint, and we are using an OAuth 2.0 client already. I am part of a team of developers in-house that have worked on this. At this time, the IPS API does not fulfill our needs.

From what I can tell from the IPS documentation, I don't think webhooks or an SSO application would allow us to create members in IPS. I think that IPS should make improvements to the database schema to bring it up to best-practice standards, but this was already requested in 2021 in the other thread. Thank you for your time and input. I think we will put this modernization project on hold for now until we have time to make bigger changes to uncouple our internal software from IPS.

Our software needs to know the IPS ID for all of our users, which means that accounts need to be created in both Oauth and IPS at the same time. We have disabled the standard login, but there is no way to create a user without a password through the IPS API. This is a critical use-case for us, which is why we have implemented this work-around. Again, are there any technical limitations on adding primary keys to these database tables, either from your end or ours? This is an oversight in IPS's database design, as using SQL without primary keys is bad practice for both performance and database normalization.

Hi, I just checked with my colleague. What we do is the following: Create the account in OAuth, like you said. Create the account in IPS through the API; IPS will not create an account automatically from OAuth. Access the IPS database directly to disable the user's password When the user logs in with Oauth to IPS, IPS links their IPS account to the one in our Oauth system. If we did not disable the password, the system would ask the user for their IPS password before linking to OAuth. We don't want users to have to set two passwords, as that would be a bad experience for our users. With the way IPS is coded, there is no way for us to use the OAuth integration without direct access to the database, or forcing all of our users to set two separate passwords to use our service. If 2, 3, or 4 could be solved with either a custom application or code changes from your end, we would happily switch to that and convert our self-hosted subscription to IPS Cloud. Is there someone we can talk to about the database schemas to resolve this issue with the database?

Hi Jim, Thanks for your response. I was wondering if there's a deeper technical reason for not using primary keys on these tables? I understand that there is a standard policy around not modifying the database schema, but primary keys have been best practice for decades at this point, and auto_increment keys do not affect existing SELECT or INSERT queries. Other forums software such as Discourse does not have this issue with primary keys. I would be interested in a way to create a member using the REST API or custom application API. The existing API requires the caller to set a password for the new user, which isn't applicable for an OAuth environment, and would cause a security risk if we did not access the database directly. If there is a way to create new members without setting a password, that would probably convert us into an IPS Cloud customer. - Justin

Hi, I'm a cloud engineer maintaining a large IPS forum with ~200k users. We've been using IP.Board since the early days, but we're needing to migrate our forum to a more modern server in order to keep it maintainable by our small team. We've looked into IPS cloud as a modernization option, but the current offering isn't viable for us. One of our requirements is that we need to be able to create members from our other internal microservices, and allow these members to login with oauth. At the moment, this isn't possible with the API, and requires direct access to the IPS MySQL database. So, in order to modernize our forums hosting infrastructure, we are moving our forums from our outdated AWS monolith, to a modern containerized Digital Ocean system. One important change with this new infrastructure is that Digital Ocean's managed MySQL databases require primary keys on all tables. It is not possible for us to use tables without primary keys on our new infrastructure. We have been able to run IPS in our Kubernetes containers just fine on our new servers, but the main roadblock we've encountered here with the IPS software is that many of the tables that it uses do not have primary keys, which is preventing us from migrating our forums to our new server. Other forums software such as Discourse do not have this database issue. The solution we've come up with internally is to simply issue ALTER TABLE commands for these tables to add an auto_increment primary key, which will add a primary key to these tables without affecting IPS's database code. We wanted to get your input on the impact of such a move. Are there any possible issues that you can see with this auto_increment plan, and are there plans to update these IPS tables to use primary keys by default in the future? This post is a continuation of another discussion, I'm creating a new post to avoid excessive necromancy. Thanks, Justin