Geek Answers Handbook

Umbraco magically returns to “Looks like there's more work out there,”

I have a client, and he said that 5/6 times, the website somehow returned to unpublished mode. We are not sure what could be causing this, and usually it will happen when no one is working on the website at all. They have some people who are in the past and may still have malicious intentions to bring the site down (so that could also be a problem).

  • Are there any known security issues in Umbraco that could result in a malicious user publishing an entire website?

  • Are there any errors in Umbraco that can lead to this?

  • Does Umbraco check the database for the published flag, or just check for the presence of an XML file before selecting the message "there is more work"?

+4
source share
3 answers

Umbraco will show this page if it cannot connect to the database.

In earlier versions of Umbraco, when this happened, the site will remain in that state until it is republished - this seems to be fixed (I'm not sure which version). If you suffer from this, and updating is not an option, then a workaround is to place the following code at the top of /config/splashes/noNodes.aspx:

<script runat="server"> protected void Page_Load(object sender, EventArgs e) { Server.ScriptTimeout = 100000; var cacheFile = IOHelper.MapPath("/App_Data/umbraco.config"); try { var r = XmlReader.Create(cacheFile, new XmlReaderSettings() { DtdProcessing = DtdProcessing.Ignore }); var d = new XmlDocument(); d.Load(r); var n = d.SelectSingleNode("//root"); r.Close(); if (n.ChildNodes.Count == 0) { Response.Write("Republishing Site......"); Response.Flush(); } else { Response.Write("Site Was Already Published......"); return; } } catch (Exception ex) { Response.Write(ex.Message); Response.Write("Cache missing, republishing....."); Response.Flush(); } Document.RePublishAll(); library.RefreshContent(); Response.Write("Completed"); Response.Flush(); Response.Redirect("/"); Response.End(); } </script>

(This code was not originally mine - I can’t remember where I got it from). The code tries to republish the site so that immediately after connecting to the database the site appears again.

You can also edit the contents of /config/splashes/noNodes.aspx to show your users site maintenance or an error message that is more appropriate.

Are you aware of any scheduled maintenance of the database at the time your customers were hit? If not, you may need to take a look at their hosting.

+2
source

The message you are referring to exists in the /install/noNodes.aspx file.

This indicates that the site, or at least the site’s homepage, has not been published. This indicates that either someone or the process has not published the site or homepage. Firstly, I would set that the "non-public" date on the "Properties" tab is not displayed on the main page.

Also check the Umbraco logs to see who does not publish which nodes and when. You can also check the audit history on the home page to see who edited it.

If you suspect malicious intent, then you need to pre-attach your security before addressing security issues with Umbraco. You need to consider changing passwords for both the RDC server, SQL sa, and for any specific Umbraco passwords.

+3
source

I would repeat everything that Digbyswift said, besides, the pages of the site actually appear as unpublished in the back office? If they are still published (i.e., they are not grayed out), but they are not displayed in the interface, then someone can set the publication date without publishing on the properties tab. If it is saddled, then someone physically did not publish it, possibly through the back office).

If it appears as published but has nothing at the front end, it is also possible that something went wrong with the cmsContentXml table. When this happens, make sure there are entries in this table. If they are not there, the site will consider it empty, because the XML cache of the site will be restored from this table when the site starts. If the table is empty, someone or something cleans it, which should not be.

If you suspect that a malicious user, reset ALL passwords for the system (back office users, AND database) and make sure that everyone who has access to the CMS has their own username and password (and make sure that they are not find out each other’s details), so you can bind changes to specific users using the audit trail.

+1
source

More articles:


All Articles