I am experimenting with API functions in a test installation. Now looking at the domains_domain_* functions. These functions update the 'domains' table. Is there some documentation that explains what this table is or where it fits into the topology? I'm trying to build an environment from scratch almost entirely using the API. The pattern I think that needs to be followed is to start with a Remote User, and get a Session ID with login(). Then create a client and get the internal/generated client_id. For email, then use mail_domain_add, then create users for that domain, then aliases for those users, etc... Working with sites involves the web_domain table with site_* functions. I started getting lost when I found that I can create 'domains' records with invalid client IDs (accidentally) and I don't see these showing anywhere in the UI except in the data logs. Records in mail_domain with invalid clients show up in the Email list. Thanks!
This table is used for the domain limit module, it allows an admin to restrict which domain names a client or reseller may use in ISPConfig.
There's not much current developer documentation, you've probably seen the api docs and remote api examples, that and the discussion here and in gitlab is all I know of. There's some online developer documentation which is probably accurate for a quite older ISPConfig version, but is not updated for current versions. As it relates to your other discussions of blogging and documenting, you might be interested in putting together a comprehensive documentation of the schema? Others might have ideas on a format, but documentation that is maintained inline with the code certainly has advantages; I'm familiar with phpdoc style documenting, but nothing for sql offhand (it probably exists). But a nice top-down overview would also be quite useful. The "what's in each table" is pretty easy to grasp, but getting in to how things are used and relate (in particular the user/group type relations) could be quite useful. In what language? I have the start of a php class for interfacing with the API if you'd like a copy. I'm developing it along with a program to migrate a custom-built mail system to ISPConfig, so the mail related api functions are about all that are currently covered. (eg. I manually created the client and added the domain, those functions aren't present) I'm writing it with the intent to publish at some point (ie. all the internal migration logic and such is not in this class), but it needs a lot more work to cover the complete api. Yep, manually create a remote user with the needed permissions (which will probably be everything for your use case). You login to get a new session id every time your program runs; cache the session id to reuse for the entire session, then destroy with 'logout' when done. Probably check for an existing client and create if needed. This part is very specific to how you structure your domains in ISPConfig, eg. if you use clients at all, or only a single admin, and if you use resellers or not. Basically learn how everything works and is or can be setup via the ui, then emulate that with the api. Yes, the api is largely just an interface to the database tables, and will usually accept what you send, whether that's consistent/correct or not. It can be a feature, eg. you can create a mail alias first before creating the mailbox to which it forwards, but it does mean you have a lot more testing to do on your side because you can't just rely on an error to be thrown if you send inconsistent data.
@jesse - (Really, thanks for time, man.) I originally started with the CSV/email import script, saw how that works, saw the rest of the API, and quickly started connecting dots. I'm ready to submit a PR for a single page doc update. Right now I'm just running tests through Postman. Coding languages are irrelevant for the general purpose of monkeying with the API. As a personal project I'm generating data and API queries using a dialect of BASIC in a business system, not helpful to anyone here. I figure if I can get that working I'll have a solid handle on the API @Th0m, when you see my PR for #5694 you'll see how I'm approaching this, and that might help to craft a disclaimer that matches what's happening. BTW, even more OT, I can't see the doc subdomain, others might not either. See attached screenshot. Thanks guys!
Yes, it means that after visiting it over https, you can't visit it over http anymore because HSTS is set. Again, I think we should bring the whole site down, protect it with a password, show a placeholder, or something like that.
The docs site was a http only site, so you must have got an error when you type in https://. I've enabled https for that site now.
He could have visited https://ispconfig.org/ which sends strict-transport-security: max-age=31536000; includeSubDomains and therefore includes the docs subdomain.
