CMS MADE SIMPLE FORGE

SitemapMgr

 
Back Back to List

[#11756] Support protected sites using basic authentication

avatar
Created By: Lew Shepherdson (lew)
Date Submitted: 2018-02-26 01:24

Assigned To: Rolf (rolf1)
Resolution: Won't Fix
State: Closed
Summary:
Support protected sites using basic authentication
Detailed Description:
I'm replicating what I entered at
https://forum.cmsmadesimple.org/viewtopic.php?f=7&t=77925&p=337035#p337035

I installed SitemapMgr as per the instructions, but could not get the default
"Pages" sitemap to be created, even after creating the required template.

In Admin Log, noticed lots of CmsJobManager lines with "Received 401 response
when trying to trigger async processing" and realized HTTP error 401 has to do
with authentication. This new site I was testing was "protected" behind
.htaccess-enabled userid/password authentication. As soon as I commented out the
authentication lines in .htaccess, then SitemapMgr immediately worked and
created the expected sitemap-pages.xml file.

Just to verify, in SitemapMgr.module.php, in function CreateSitemap, just before

$req->execute( $url );

line (#129), I inserted

$req->setAuth('myHardCodedUser', 'myHardCodedPassword');

to provide the authentication required. It worked as expected, even when the
.htaccess authentication was enabled.

Feature request is to provide input fields in the SitemapMgr admin page where,
if the site is being protected, authentication credentials can be entered.

Thanks for considering this.

History

Comments
avatar 
Date: 2018-02-26 08:47
Posted By: Rolf (rolf1)

Hello,

A xml sitemap is created for search engines to read, for improving content
indexing.
If your website is protected so regular users *including* search engines can't
visit it, the sitemap is redundant in my opinion.

Or I don't understand the request/problem and you need to explain that some
more....

grtz. Rolf
avatar 
Date: 2018-02-27 01:09
Posted By: Lew Shepherdson (lew)

You're quite correct.  In this case, the protected website is a "staging clone"
of the production site - among other reasons it is protected so that Google
can't ever replicate the index for the cloned set of pages.

At some point, the upgrades and other changes on the site are going to be
promoted to the unprotected production site.  Because the policy is that no
changes that haven't been tested/proven on the "clone" are allowed to be
migrated to the production site, we're currently in a "catch-22" where we can't
clone SitemapMgr to production if it doesn't work on the clone and we can't get
it to work if it's on the "protected" clone site.

QA also get bent out of shape by the "401" errors from CmsJobManager in the
AdminLog. The alternate solution is that the "staging clone" site needs to be
moved onto a network not accessible from the Internet (in particular by search
engines), so that it doesn't need to be "protected".

Lew
avatar 
Date: 2018-06-07 15:50
Posted By: Rolf (rolf1)

I have looked into this again and have come to the conclusion I will not "fix"
this.
Simply because when you have set up the SitemapMgr module, you can disable it in
Module Manager.
It will still be installed but it won't function and generate error messages.
When the website is set life, enable the module again and you're dome...

Grtz. Rolf
Updates

Updated: 2018-06-21 15:26
state: Open => Closed

Updated: 2018-06-07 15:50
resolution_id: => 8