Before I involve a developer and you begin tinkering, I wonder if some of AtoM's existing functionality might meet your needs? There are a couple different features that if used together might give you close to what you want without needing to make any local customizations. This in turn means you don't need to maintain your custom development and future upgrades will be much easier.
First, AtoM has the ability to globally hide the login button, via the Visible elements module. See:
To login your users would need to manually navigate to /user/login, reducing the likelihood that public users will even see the login page. Staff can simply bookmark the login page for example.
Now to ensure that even those who find the login page cannot login unless their IP matches a specific range, AtoM has a security setting that will ensure that only users from a specific IP range can gain administrator abilities - any other attempts to login as an administrator from a different IP will be denied. See:
DO NOT TURN THIS ON unless you are ready to use it, and have already confirmed the IP range you will be requiring - we have had many users accidentally lock themselves out of their AtoM site when experimenting with settings like this!
There are also a couple of other security settings in this section that might be of interest, such as requiring an HTTPS connection to be able to login, and requiring strong passwords. See:
Finally, an additional way to add more security, while also being able to optimize the public site's performance via caching etc, is to use a 2-site deployment, instead of just one site for everything. This is a service we offer to our Premium+ hosted clients, but we make the script involved publicly available for those who would like to use it themselves.
Essentially, you deploy two AtoM sites. One is a public facing read-only site, where login is completely disabled. The second is an internal read-write edit site for staff, typically deployed behind a firewall. The last piece is a replication script that when run, will copy the database and search index to the public site on demand. This allows for a number of advantages, such as:
- Increased security: login can be fully disabled in the public site. The edit site can be deployed behind a firewall and its URL kept from being publicly indexed.
- The ability to optimize each site separately: You can install an additional caching engine on the public front-end (we often use Varnish, and have ensured that AtoM's 2-site deployment can work with Varnish) and cache aggressively, so that public reads are much faster. Internally, you can ensure more CPU and RAM for editing, etc.
- Better visibility control for other entities: currently only archival descriptions in AtoM have a publication status, allowing you to hide Draft descriptions from public users. With the replication script, records are only copied to the public site when the script is manually run, meaning that you have a way of controlling when authority records and other AtoM records become publicly visible.
For more information, see:
Note that, while the slides still provide an overview of the process, the replication script they link to has been replaced with an improved updated version, available here:
So, taken together, these do not provide exactly what you are looking for... but they come close. IF not, then perhaps by studying some of the existing security module code, you will find what you want (since there is already functionality to limit by IP range, for example). A few files I found that you can review:
Hope that helps.