AtoM - Change login page

Skip to first unread message

William Gustavo Ourives Maciel

Sep 25, 2023, 3:29:18 PM9/25/23
to AtoM Users
Hello. I'm new to AtoM and I need to change the application's home page so that if a request comes from the internet, the login option is not available. I'm thinking about changing a part of the "php" script so that if the IP range of the request is not from our Intranet, the login option will not be presented.

William Gustavo Ourives Maciel

Sep 25, 2023, 3:34:33 PM9/25/23
to AtoM Users
the question is where and which file should I change

Dan Gillean

Sep 26, 2023, 9:36:52 AM9/26/23
Hi William, 

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. 

The features: 

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. 

Note: I suspect that dynamically checking the IP and then deciding whether or not the login button loads into the header will be much more complex, and will require additional JavaScript on top of the backend code to check the IP. If you are willing to use the existing option to globally hide the login button via Visible elements, and then extend the existing IP range check so that it blocks ALL logins not from a specific range (instead of just Admin logins), this will probably be a lot easier to implement. Just a thought! 


Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
he / him

You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

William Gustavo Ourives Maciel

Sep 26, 2023, 1:00:03 PM9/26/23
to AtoM Users

Hello Dan Gillean! Thank you very much for the clarifications. It really helped me. The proposal of not exposing the login screen combined with the range of specific IPs is an excellent option. Thanks again for the support.

Book Club

Sep 27, 2023, 3:27:09 PM9/27/23
Please remove me from mailings

Reply all
Reply to author
0 new messages