For Sitecore, specify MongoDB connections in lower case…

You wouldn’t think this was 2017, but here we are again struggling with upper and lower case again.

In a Sitecore instance I had the following connection string to MongoDB:

<add name="analytics" connectionString="mongodb://mongo.ourserver.local/XXXX_analytics" />

However, something was wrong with the instance; installing packages on it didn’t work (which is VERY strange – why does it need MongoDB? That doesn’t make sense! Anyway…)

Looking in the log, I found:

36404 00:00:26 ERROR Exception when executing agent processing/taskAgent
Exception: MongoDB.Driver.MongoCommandException
Message: Command 'findAndModify' failed: exception: db already exists with different case already have: [xxxx_tracking_live] trying to create [XXXX_tracking_live] (response: { "errmsg" : "exception: db already exists with different case already have: [xxxx_tracking_live] trying to create [XXXX_tracking_live]", "code" : 13297, "ok" : 0.0 })
Source: MongoDB.Driver
at MongoDB.Driver.Operations.CommandOperation`1.Execute(MongoConnection connection)

Ah. So MongoDB would happily:

  • Try to find the repository with the name containing capitals (“XXXX_analytics”)
  • Correctly fail (repository doesn’t exist), and then create the repository with the name rendered to lower case (“xxxx_analytics”)
  • Try to find the repository with the name containing capitals again (“XXXX_analytics”)
  • Incorrectly fail to find the repository due to the case difference, and then try to create the repository a second time with the name renadered to lower case.

This is stupid. If one method ignores case, so should the others.  I don’t mind which way it works – obey or ignore case – but it needs to be consistent.

For Sitecore, specify MongoDB connections in lower case…

Turn off Auth on Solr

Okay, so you probably shouldn’t be doing this – but should you install Solr using the Bitnami stack – like I usually would – it will ask you to set up a usename and password to connect with.

This is a good thing (much better than MongoDB’s “Insecure by default” configuration) – but what if you don’t want it (e.g. for your shared dev Solr instance)?

  • Edit \solr-xxxx\apache-solr\conf\solr.conf
  • Set AuthType to “None”
  • Remove “Require User ” line
  • Restart service.

That should do it.

Turn off Auth on Solr

Securing MongoDB (Brief Notes)

So, Sitecore uses MongoDB, a product that has an interesting approach to security. When you install it, by default, it doesn’t have any. By Default:

  • Mongo does not require authentication
  • Communication is unencrypted
  • In fact, if you can connect to it, you can bugger about with the data

This is, ahem, “suboptimal”. It is, however, possible to to set it up. Options:

  • Restrict IP address access at the firewall. Good practice, to be honest, and not covered here.
  • Configure to use SSL
  • Configure to use a username/password in connection strings

Continue reading “Securing MongoDB (Brief Notes)”

Securing MongoDB (Brief Notes)

Sitecore Serialization – System.ArgumentException: Illegal characters in path

So, I was trying to use Sitecore Serialisation, and I got the following error:

System.ArgumentException: Illegal characters in path.
at System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
at System.IO.Path.IsPathRooted(String path)
at Sitecore.Data.Serialization.PathUtils.MapItemPath(String itemPath, String root)

capture-serialization-page

Joy. Sadly, this pad doesn’t give a clue what the problem item actually is. The log files don’t show an exception – but I can see the last item processed, and it looks funny:

capture-of-log-file

So, if that’s the item throwing the exception then a) serialisation isn’t logging the exception, which sucks, and b) some items in this tree have newline or carriage return characters (\n or \r)

To try and find these, I ran SQL against the database…

SELECT * FROM [MASTER].[dbo].[Items]
where Name like '%' + CHAR(10) + '%'
or Name like '%' + CHAR(13) + '%'

This found a bunch of items with \r in their names. Lord knows how they were put there. I suspect copy and paste from some of the actual content.

Sitecore Serialization – System.ArgumentException: Illegal characters in path

Sitecore Permissions

Sitecore permissions are always a bit of a pain to figure out. You’ve got the question of inheritance of rights from parent nodes, and how role rights conflicts are resolved.

Well, these two links are particularly useful, I found:

There’s quite a lot of reading there, but it’s good content. The easiest way I’ve found for considering permissions is:

Unspecified (effectively no-access) is beaten by Inherited rules (variable) is beaten by Allowed (has access) which is beaten by Deny (No access).

In other words, an explicit Deny will block access to a user.

If there is a conflict between explicitly assigned roles, Deny wins.

If rights are assigned directly to a user (rather than a role) they win – though you shouldn’t be assigning rights directly to users. It’s unmanagable in the long term.

Simple, right?

 

Sitecore Permissions

Minifying JS – Skip removing line numbers?

I’m a big fan of App Insights, and I’m loving it’s increasing integration with Visual Studio. To me, it’s just great.

However, I did find myself laughing a bit at this. App Insights was recording JavaScript errors from a (third party’s) .JS file.

appinsights

This is showing an error on Line 93. The thing is, the file has been minified – and all the code in the file is on line 93.

Hmm. All this would save is a couple of hundred bytes over the wire. I’m just not sure it’s worth it for most of the projects I work on. I think having the new-lines still in (albeit otherwise minified).

To be honest, we’d save more space by stripping out the 92 lines of Licensing information above the code. I’m not sure that that shouldn’t reside in a text file, and just have a comment referencing the licence information.

Minifying JS – Skip removing line numbers?