Staff sign in to the admin area with their own account. What each account may do comes from its role. This chapter covers the pages under Settings > System that deal with staff and access (Administrators, Administrator Roles, Two-Step Sign-In, API Credentials, Banned IPs, Banned Email Domains, Security Questions), the logs under Utilities, staff sessions and sign-in lock-outs, the My Account page, and what CoreInto encrypts.
Administrators
Settings > Administrators lists every staff account: name, username, email address, role, whether two-step sign-in is on, the last sign-in with its IP address, and Active or Disabled. Your own row is marked "you". Needs the permission "Administrators".
Adding and editing an administrator
Press Add Administrator, or open a name in the list. The form has three parts.
Account
| Field | Notes |
|---|---|
| First name, Last name | First name is required; up to 100 characters each. |
| Username | 2 to 64 letters, digits, dots, dashes or underscores. Must be unique. |
| Email address | Required. Used for staff notices and password reset links. |
| Role | Only roles whose permissions your own role has are listed: you can only give out what you hold. |
| Status | "Disabled: cannot sign in, and API credentials acting as this administrator stop working." You cannot disable your own account. |
Password
| Field | Notes |
|---|---|
| New password, New password again | Required for a new administrator. When editing, leave empty to keep the current one. Must meet the password rules (at least 10 characters and the strength set under General Settings, Security tab). |
| Ask for a new password at the next sign-in | Ticked by default for new accounts. The administrator is taken to My Account to choose a password before any other page opens. |
Other details
| Field | Notes |
|---|---|
| Ticket reply signature | Added to the administrator's ticket replies. |
| Private notes | Seen only on this page. |
Setting a new password or disabling the account signs that administrator out of every session (your own current session is kept when you change your own password here).
When editing an existing administrator, a Security box shows whether two-step sign-in is on and the last sign-in, with these actions:
| Action | What it does |
|---|---|
| Turn Off Two-Step Sign-In | For an administrator who lost both phone and recovery codes. Ends their sessions; they can set it up again under My Account. |
| Sign Out Everywhere | Ends every session of that administrator and closes their open entries in the Staff Sign-in Log. |
| Delete | Shown only for an administrator who has never signed in and is not you. Anyone who has used the system cannot be deleted, only disabled, so the records that name them stay whole. |
Every change is written to the activity log ("Changed administrator jane: role to Sales Operator, password").
Rules that protect access
- At least one enabled administrator must always have full access. A change to staff or roles that would leave none is refused as a whole ("At least one enabled administrator must keep full access.").
- You can only give roles, and permissions, that your own role has.
- You cannot change an administrator whose role has permissions you do not have. The page answers 403 with "This administrator has permissions you do not have, so you cannot change the account."
- You cannot disable or delete your own account.
Administrator Roles
Settings > Administrator Roles lists each role with its number of permissions ("Full access" or "15 of 153"), how many administrators have it, and which staff notices it receives. Needs the permission "Administrator roles".
Three roles are made at installation:
| Role | Holds |
|---|---|
| Full Administrator | Every permission ("*"), every dashboard widget, every report; receives system, order and account, and ticket notices. |
| Sales Operator | Clients, users, services, domains, orders, invoices, transactions, quotes, credit, support reading and replying, announcements, knowledgebase, downloads, network issues, calendar, to-do, WHOIS and the resolver; receives order and account notices. |
| Support Operator | Support overview, tickets, scheduled ticket actions, predefined replies (use and edit), announcements, knowledgebase, downloads, network issues, to-do list and the credit log; receives ticket notices. |
Actions on the list: Copy (opens a new role form filled from this one, named "... (copy)"), Duplicate (saves the copy at once and opens it), and Delete (only for roles with no administrators; move them to another role first).
The role form
| Section | What it holds |
|---|---|
| Role name | Up to 100 characters, unique. |
| Staff notices by email | Three boxes: System notices (automation results, errors); Order and account notices; Ticket notices. Staff emails such as "new order", "client changed their details", "module action failed" or "ticket reply" go to every enabled administrator whose role has the matching box ticked. |
| Permissions | One tick box per permission, grouped as below. "all" ticks a whole group. Staff with full access see a "Full access" box that gives every permission, including ones added in later versions. Permissions your own role lacks are greyed out: you can only give what you have. |
| Dashboard widgets | Which dashboard panels members see: Counters; Billing totals (also needs "See income totals"); Automation overview; Client activity; To-do list; Recent activity (also needs "Activity log"); Staff online; System information; Support overview; Network issues; My notes. The last three have no panel on the dashboard in this version. |
| Reports | Which reports members may open when the role has "View reports": "All reports, including ones added later", or a tick per report (the 23 reports plus Batch Invoice PDF). The Reports menu hides the rest. |
Permission groups
| Group | Permissions |
|---|---|
| General | Dashboard; Statistics in the side column; See income totals; Change own account and password; See what is new |
| Clients | List and search clients; View client summary; Add, Edit, Delete clients; Sign in as a client; View, Add and edit, Delete client notes; Manage client files; Manage saved payment methods; Export a client's data; Send mass email; List users; View users of an account; Manage users; Delete users; Manage affiliates |
| Services and domains | List services; List service add-ons; List domains; View, Edit, Delete services; Run module commands (create, suspend, terminate...); View, Edit, Delete domains; Run registrar commands; View cancellation requests; Create upgrade and downgrade orders; View failed module actions |
| Orders | List orders; View order details; Add orders; Accept, cancel and change orders; Delete orders; Use any promotion code on an order |
| Billing | List, Add, Edit, Delete transactions; List, View, Create invoices; Edit invoices and add payments; Cancel, Delete invoices; Refund payments; Generate due invoices; Charge saved payment methods; Create add-funds invoices; View, Manage billable items; Manage quotes; View the credit log; Add and remove credit; List, View, Create, Manage, Delete credit and debit notes; View the gateway log; View gateway balances; Manage payment disputes |
| Support | Support overview; List, View, Open, Delete tickets; View tickets flagged to others; Open tickets of any department directly; Manage scheduled ticket actions; Use, Create and edit, Delete predefined replies; Manage announcements; Manage the knowledgebase; Manage downloads; Manage network issues |
| Reports and utilities | View reports; Export data; Automation status; Email marketer; Link tracking; Calendar; To-do list; WHOIS lookups; Domain resolver check; Integration code; Import data; Use add-on modules |
| System | Database status; System cleanup; System health; Update CoreInto; Activity log; Staff sign-in log; Email log; Ticket mail import log; WHOIS log; Module log; API log |
| Settings | One permission per settings page (General settings, Automation settings, Storage settings, Administrators, Administrator roles, Two-step sign-in, API credentials, Currencies, Payment gateways, Tax rules, Products and so on), with finer ones for promotions (view, create and edit, delete), products (view, create, edit, delete, manage product groups), email templates (view, create and edit, delete, languages), banned addresses (view, ban, lift bans), plus Configure add-on modules and Sign-in integrations. Settings > Languages uses the General settings permission |
A page that a role may not open answers "Your administrator role does not allow this page." Menu items the role may not use are hidden.
Two-Step Sign-In
Settings > Two-Step Sign-In has one setting and a list. Needs the permission "Two-step sign-in".
- Require two-step sign-in for all staff. When ticked, every administrator without two-step sign-in is sent to My Account to set it up before any other page opens, and nobody can turn their own off. Saving the change is written to the activity log.
- Staff lists each enabled administrator with their role and "On" or "Not set up" (shown in amber when it is required). Staff with the Administrators permission get a Turn Off button next to anyone who has it on, for the case where phone and recovery codes are both lost.
How a staff member sets it up for themselves is under "My Account" below. Codes are the usual time-based six-digit codes (a new code every 30 seconds); the code from the current half minute and the ones just before and after are accepted, and a code is never accepted twice.
API Credentials
Settings > API Credentials manages the identifiers and secrets other programs use to call CoreInto's JSON API. The page shows the address programs call (https://billing.example.com/api/v1/) and the header they send (Authorization: Bearer IDENTIFIER:SECRET). The API itself, its actions and answers are described in API; the API Reference button on this page opens the same list inside CoreInto. Needs the permission "API credentials".
The list shows each credential's description, identifier, which administrator it acts as (marked "disabled" when that account is disabled), its access ("Everything" or a count of areas), allowed addresses, last use with its address, and expiry (with an "expired" badge when past).
Adding a credential
| Field | Notes |
|---|---|
| Description | Required, for example "website order form". |
| Acts as administrator | The credential works as this administrator: changes made through the API are logged under that name. Only enabled administrators whose permissions you hold are offered. Cannot be changed later. The form says the administrator's role also limits the credential, but in this version the API checks only the credential's scopes, so give a credential no more than it needs. |
| Allowed addresses | One address or range per line (203.0.113.7, 198.51.100.0/24, 203.0.113.*, 2001:db8::/32). Empty: any address. |
| Expires on | A date after today, or empty for never. |
| What it may reach | "Everything", or tick scopes: clients, orders, services, domains, billing, support and system, each as read or write, and products read. At least one is required. |
After Create Credential the page shows the identifier and the secret once, in a "Copy the secret now" box. CoreInto keeps only a fingerprint (SHA-256) of the secret and cannot show it again. If it is lost, use Make New Secret on the credential's page: the old secret stops working at once. Delete removes the credential; programs using it can no longer connect.
A credential stops working when its administrator is disabled, when it expires, when the call comes from an address not on its list, or when its scopes do not cover the action. Every call is written to the API Log. Ten failed sign-ins from one address lock the API for that address for 15 minutes.
Banned IPs
Settings > Banned IPs lists addresses and ranges that may not sign in, register or check out. Viewing needs "View banned addresses"; the form needs "Ban addresses"; Lift Ban needs "Lift bans".
Ban an address. Enter an address (203.0.113.7) or a range (203.0.113.0/24, 203.0.113.*, 2001:db8::/32), an optional reason, and how long: 1 hour, 1 day, 1 week, 30 days or Permanently. A range is stored in its normal form (203.0.113.0/24). You cannot ban your own address; the page shows what it is. Banning a range that is already banned replaces the old ban.
The list shows address, reason, when it was banned and until when ("Permanent"), with a search box over address and reason. Expired bans are removed by the daily prune task. Lift Ban removes the ban and also clears the failed sign-ins that caused it.
Bans are also added automatically: after too many failed sign-ins from one address (General Settings, Security tab: "Failed sign-ins before a ban" and "Minutes an address is banned after failed sign-ins") an entry "Too many failed sign-ins" is added, unless the address is on the "Addresses never banned" list. A banned visitor who tries to sign in sees "Too many failed sign-ins from your address. Try again after ...", and checkout refuses the order.
Banned Email Domains
Settings > Banned Email Domains lists domains at which nobody may register or set their email address, useful against throw-away mailboxes. Enter a domain such as mailinator.com (an address like someone@mailinator.com is accepted and reduced to the domain; international names are stored in their ASCII form). The list shows the domain and how many sign-ups it stopped; Remove takes it off the list. Needs the permission "Banned email domains".
Security Questions
Settings > Security Questions holds the questions a user can choose from on their client-area Security page, with an answer. The admin list shows each question and how many users chose it; edit the text in place and press Save, or Delete (users who chose it are left with none). Needs the permission "Security questions".
Staff use the answer to confirm who they are speaking to, for example on the phone: on a user's page under Clients > Manage Users, staff who may manage users see the user's question with an answer box and Check Answer. CoreInto answers "The answer is right" or "The answer is not right" (case does not matter) and writes the check to the activity log. The stored answer is hashed and cannot be read back.
The logs
The logs are under the Utilities menu. Each log page has filters at the top (dates From and To in the company's time zone, and the fields below), a table, and pages of "Records per page" rows. The date filter and text filters combine.
| Log | Permission | Filters | Columns and notes |
|---|---|---|---|
| Activity Log | Activity log | User, Description, IP address | Date, User, Description, IP address. Everything staff and the system do: sign-ins and failed sign-ins, settings changes, staff and role changes, bans, credential changes, orders, payments, module actions by hand, contact form messages, backups and more. Also shown per client on the client's page. Kept for the days set under General Settings, Other tab. |
| Staff Sign-in Log | Staff sign-in log | Administrator, IP address | Signed in, Administrator, IP address, Last seen (kept current while they work, at most once a minute), Signed out. |
| Module Log | Module log | Module, Action, Result (Failed only) | Date, Module, Action, Result, the start of the request. Every call to a server module or registrar, with passwords and keys masked. Click the date to see the full request and response. Kept for the days set under Automation Settings, Data retention tab (default 30). |
| API Log | API log | Action, IP address, Result (Failed only) | Date, Credential, Action, IP address, Status (HTTP code, red from 400), Time in ms. Click the date to see the request (passwords, secrets and tokens hidden) and the response. |
| Email Message Log | Email log | See Email | Every email CoreInto sent or tried to send. |
| Ticket Mail Import Log | Ticket mail import log | Sender, Subject, Result (Made a ticket or reply; Refused or ignored) | Date, Sender, Subject, What happened. Each email read from a department mailbox or piped in, and what CoreInto did with it. Click the date to see From, To, Cc and the message text. |
| WHOIS Lookup Log | WHOIS log | Domain, IP address | Date, Domain, IP address. Every WHOIS lookup made by the domain search or Utilities > WHOIS Lookup. |
A module log entry that is gone answers "That log entry does not exist (old entries are removed by the daily run)."
Sessions
A signed-in browser holds a random token in a cookie (ci_admin, or __Secure-ci_admin over HTTPS); the database holds only a hash of it. PHP's own session system is not used.
- A staff session ends after 1 hour without a request, and in any case 12 hours after sign-in. Client sessions end after 2 hours idle or 24 hours.
- While a sign-in waits for the two-step code, the pending session lasts 5 minutes.
- End a staff session when its address changes (General Settings, Security tab, default on): a request from a different IP address than the one the session was started from ends the session and sends the staff member back to the sign-in page. Turn it off for staff whose address changes while they work.
- Signing in always starts a fresh session; a session token planted in the browser beforehand is discarded.
- Every form post must carry the session's token and come from this site; otherwise the page answers "The form had expired. Go back, reload the page and try again."
- The Staff Online dashboard widget lists administrators with a request in the last 15 minutes.
- Sessions idle for a day are removed by the
prunetask. Changing a password, disabling an account or "Sign Out Everywhere" end the sessions at once.
Behind a reverse proxy, the visitor's address is taken from X-Forwarded-For only when the request comes from an address listed in trusted_proxies in configuration.php; see Getting started.
Sign-in lock-outs and the limiter
CoreInto slows down password guessing with counters kept in the database (app/src/Limiter.php). Two counters are kept for each sign-in attempt: one for the visitor's address (an IPv6 visitor counts with their whole /64 block) and one for the account name (staff:jane or the user's email).
| Where | Limit | Then |
|---|---|---|
| Staff and client sign-in | "Failed sign-ins before a ban" failures (default 5) within 15 minutes, per address and per account | The address and the account are locked for "Minutes an address is banned after failed sign-ins" (default 15), and the address is added to Banned IPs for the same time unless it is on "Addresses never banned". Each failure is written to the activity log. |
| Two-step code | 5 wrong codes | The pending sign-in ends and counts as one failed sign-in. |
| Forgotten password (staff and client) | 5 requests per address in 60 minutes | Locked for 60 minutes: "Too many requests from your address. Try again in an hour." |
| API | 10 failed credentials per address in 15 minutes | HTTP 429 for 15 minutes. |
| Licence check-in | 30 unknown keys per address in 15 minutes | HTTP 429 for 15 minutes. |
| New tickets from the client area | 10 tickets per address in 60 minutes | "Too many tickets from your address. Please try again later." for 60 minutes. |
| Contact form | 5 messages per address in 60 minutes | Locked for 60 minutes. |
| Knowledgebase "was this useful" votes | 1 vote per article per address per day | Further votes are ignored. |
A successful sign-in clears both counters. A staff password reset by email clears the account's counter. Lifting a ban on the Banned IPs page clears the address's counter. Unknown usernames take as long to answer as wrong passwords, so the response time does not reveal which names exist.
My Account
The user menu at the top right opens My Account (permission "Change own account and password"). An administrator who must choose a new password, or who must set up two-step sign-in because it is required, lands here with a notice and cannot open other pages until it is done.
Language (shown when more than one interface language is installed): choose "Language of the admin pages" from the installed languages, or "The default" to follow the Default language setting, and press Save. See Languages.
Change Password: current password, new password twice. The new password must meet the rules. Changing it signs you out of your other sessions; the current one stays. Written to the activity log as "Changed own password".
Two-Step Sign-In:
- Press Set Up and enter your current password.
- Scan the QR code with an authenticator app, or type the key shown. The entry is named after the company and your username.
- Enter the 6-digit code from the app (and your password again) and press Turn On. If the code is refused, check the time on your phone.
- CoreInto shows eight recovery codes in the form
xxxx-xxxx-xxxx-xxxx. Keep them safe: they are not shown again, and each works once in place of a code from the app when the phone is lost.
To turn it off, enter your current password and press Turn Off. This is refused while two-step sign-in is required for all staff. Both changes are written to the activity log.
The command php cli.php reset-admin NAME also turns two-step sign-in off for an administrator and gives them a new password; see Command line.
What is encrypted
Secrets in the database are encrypted with AES-256-GCM under the encryption_key in configuration.php (app/src/Secret.php). Each stored value is bound to where it is stored, so a value copied into another column or another CoreInto does not open there. A copy of the database alone reveals none of them; without the key, none of them can be read, and CoreInto reports "cannot decrypt the stored value (wrong key or damaged data)".
| Encrypted | Where |
|---|---|
| Staff two-step seeds | Administrators |
| Server passwords and API tokens | Settings > Servers |
| Payment gateway keys and secrets | Settings > Payment Gateways (stored as enc:... inside the module's settings) |
| Registrar keys and passwords | Settings > Domain Registrars |
| Saved payment method references (card tokens) | Clients' saved payment methods |
| Service passwords | Services |
| Domain transfer codes | Domains |
| Department mailbox passwords | Settings > Support Departments |
| Custom client fields of the "password" kind | Clients |
| The SMTP password and the reCAPTCHA secret | General Settings (settings of kind "secret") |
| The licensing signing key | Add-ons > Licensing Settings |
Not encrypted but hashed, so they cannot be read back: staff, user and security-answer passwords (bcrypt), session tokens, API secrets, password reset and email confirmation links, recovery codes (SHA-256).
Keep configuration.php with every database backup. Changing the key makes every stored secret unreadable; there is no page to re-encrypt them.
Admin forms and web firewalls
Many hosts run a web application firewall (ModSecurity with a common rule set) in front of every site. It reads each form before CoreInto does, and some ordinary admin texts look like attacks to it: an install command such as curl -fsSL https://get.intopanel.com | bash -s -- --key {key}, several lines of plain features, HTML in an email template. The firewall then answers with its own plain page, "Forbidden. You don't have permission to access this resource.", and CoreInto never sees the request.
So the admin area's script sends every form packed: the text fields travel as one base64 field, _ci_packed, and CoreInto unpacks them before it reads the form (Request::unpack). The same fields arrive as before; the CSRF check, permissions and every validation still apply; uploaded files are sent as they are. A form marked data-plain is sent unpacked. Browsers without the script (or with it turned off) send forms as usual, so they may still meet the firewall.
If a client-area page is refused the same way, ask the host to exclude the rule for your CoreInto folder, or look in the firewall's log for the rule number.