| Author |
Message |
florida225
Guest
|
 Posted:
Mon Oct 24, 2005 8:51 pm Post subject:
401 response on deleted resource gallery items |
|
|
We are getting a similar situation as mentioned below in another thread, but
more specifically we want to know why MCMS doesn't just return a 404 error?
_________________________________________________________________
Hi Jake,
if a login prompt comes then the current user does not have rights on these
items.
Please verify if these items are in a resource gallery and ensure that
sufficient rights are assigned to this resource gallery.
If these are local attachments you need to ensure that the correct
permissions are given to the channel of the posting these attachments belong
to.
Another known reason for this behaviour is that this happens if these
attachments are resource gallery items which have been deleted.
The easiest way to resolve this would be to remove the references to the
deleted resources from the postings.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no rights
New to MCMS?
Check out this book: Building Websites Using MCMS: http://tinyurl.com/6zj44
----------------------
"Jake" <Jake@discussions.microsoft.com> wrote in message
news:9F010790-B847-4E15-AAEE-1328F6FC20D3@microsoft.com...
| Quote: | Our internal search engine has picked up pages on our CMS site that cannot
be
indexed. It states that access is denied. If I navigate to these pages
then I
get a Windows/IIS login box? I have noticed that all the pages are PDF
attachments and that there are being requested from /NR/rdonlyres/ which I
believe is part of the CMS cache.
|
|
|
| Back to top |
|
 |
Stefan [MSFT]
Guest
|
| Posted:
Mon Oct 24, 2005 8:51 pm Post subject:
Re: 401 response on deleted resource gallery items |
|
|
Hi,
why should it return 404? 404 means file not found.
401 means authentication required - and if the current user does not have
rights, then the 401 is the correct response.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no rights
New to MCMS?
Check out this book: Building Websites Using MCMS: http://tinyurl.com/6zj44
----------------------
"florida225" <florida225@discussions.microsoft.com> wrote in message
news:B2CF0F39-7871-47FB-9016-02D8D287E788@microsoft.com...
| Quote: | We are getting a similar situation as mentioned below in another thread,
but
more specifically we want to know why MCMS doesn't just return a 404
error?
_________________________________________________________________
Hi Jake,
if a login prompt comes then the current user does not have rights on
these
items.
Please verify if these items are in a resource gallery and ensure that
sufficient rights are assigned to this resource gallery.
If these are local attachments you need to ensure that the correct
permissions are given to the channel of the posting these attachments
belong
to.
Another known reason for this behaviour is that this happens if these
attachments are resource gallery items which have been deleted.
The easiest way to resolve this would be to remove the references to the
deleted resources from the postings.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no rights
New to MCMS?
Check out this book: Building Websites Using MCMS:
http://tinyurl.com/6zj44
----------------------
"Jake" <Jake@discussions.microsoft.com> wrote in message
news:9F010790-B847-4E15-AAEE-1328F6FC20D3@microsoft.com...
Our internal search engine has picked up pages on our CMS site that
cannot
be
indexed. It states that access is denied. If I navigate to these pages
then I
get a Windows/IIS login box? I have noticed that all the pages are PDF
attachments and that there are being requested from /NR/rdonlyres/ which
I
believe is part of the CMS cache.
|
|
|
| Back to top |
|
|
Doug
Guest
|
| Posted:
Tue Oct 25, 2005 4:51 pm Post subject:
Re: 401 response on deleted resource gallery items |
|
|
Hi Stefan,
I work with florida255 and I have a few follow up questions regarding your
response.
Which of the background processing stored procedures is responsible for
removing deleted resource gallery items that no longer have a reference to
them? I would like to confirm that we have this stored procedure enabled in
our BCP Job.
Is it possible to schedule/automate revision history purges? If we could add
something to the existing BCP Job on our SLQ server, that would be great. Our
production site is read only so automating this would be a big help in
addressing this issue as well as minimizing DB size.
How are references to resource gallery items maintained? How are references
to resources that are uploaded through the "Insert Local Attachment" dialog?
Best Regards,
Doug
"Stefan [MSFT]" wrote:
| Quote: | Hi,
deleted resource gallery items will be removed from the database
automatically by background processing when no further reference to the
resource gallery item exists.
After removing the item a 404 - page not found will be returned rather than
a 401.
If a 401 is returned means that the items still references somewhere so that
background processing was not able to remove it.
Be aware that this also includes historical revisions of postings! So you
might need to purge the revision history to ensure that deleted resource
gallery items will be removed from the repository.
Even the physical resource will still be in the database! But it is now in a
special internal folder named "Archive Folder". So you won't see it in Site
Manager but it is still there.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no rights
New to MCMS?
Check out this book: Building Websites Using MCMS: http://tinyurl.com/6zj44
----------------------
"florida225" <florida225@discussions.microsoft.com> wrote in message
news:C2EA1A54-0C8C-4C4C-905C-EC83C46F859D@microsoft.com...
Thanks for responding.
To clarify the main concern we are having is that people have bookmarked
resources such as a .pdf or .doc and now they are getting a 401 when
requesting the object. NOTE: The anonymous web user doesn't know or should
care whether it is as a local or shared resource they are looking at.
The following is a list of some of the scenarios and their results:
1. A bookmark to a shared resource record will continue to function
independent of the posting which hosted the link. Reason: The resource
link
contains a direct reference (GUID) to the resource record itself along
with
other additional code flagging parameters. If you delete or purge the
shared
resource record you get a 401.
2. A bookmark to a local resource record will continue to function so long
as the posting containing the link is published. A deleted or expired
posting
returns the 401 and a purged posting returns a 404. Reason: The resource
link
contains a reference to the posting (GUID) and then an additional
parameter
used in a MCMS reference table to locate the resource.
3. Any URL typo in a resource record or posting root GUID produces a 404.
4. Any URL typo in a resource record immediately following the GUID
produces
a 401.
These resources are not managed in the MCMS database directly, only a
record
of reference is managed. Without the reference the file is useless and
only
takes up space on the hard drive. So we are actually dealing with two
issues:
1. Why not remove the physical resources when all their references are
gone?
2. If we can't manipulate a resource any longer through the resource or
site
manager interfaces then why serve a 401? The latter being the only
pressing
issue.
It would make a bit more sense to say to a anonymous web user "the file
doesn't exist, because we have no record of it any longer in our MCMS
database (404)" than to say "the file may or may not exist, so log in to
find
out (401) and then after you do that we will redirect you appropriately -
either to the file or to a 404."
I just wanted to know if there is a fix for this. If MCMS was designed
without considering this or it is a known bug, that is fine. I'll just
hope
for a change in the next release and introduce a process around it now for
our content developers. Please advise.
Thanks
"florida225" wrote:
We are getting a similar situation as mentioned below in another thread,
but
more specifically we want to know why MCMS doesn't just return a 404
error?
_________________________________________________________________
Hi Jake,
if a login prompt comes then the current user does not have rights on
these
items.
Please verify if these items are in a resource gallery and ensure that
sufficient rights are assigned to this resource gallery.
If these are local attachments you need to ensure that the correct
permissions are given to the channel of the posting these attachments
belong
to.
Another known reason for this behaviour is that this happens if these
attachments are resource gallery items which have been deleted.
The easiest way to resolve this would be to remove the references to the
deleted resources from the postings.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no
rights
New to MCMS?
Check out this book: Building Websites Using MCMS:
http://tinyurl.com/6zj44
----------------------
"Jake" <Jake@discussions.microsoft.com> wrote in message
news:9F010790-B847-4E15-AAEE-1328F6FC20D3@microsoft.com...
Our internal search engine has picked up pages on our CMS site that
cannot
be
indexed. It states that access is denied. If I navigate to these pages
then I
get a Windows/IIS login box? I have noticed that all the pages are PDF
attachments and that there are being requested from /NR/rdonlyres/
which I
believe is part of the CMS cache.
|
|
|
| Back to top |
|
|
florida225
Guest
|
| Posted:
Tue Oct 25, 2005 4:51 pm Post subject:
RE: 401 response on deleted resource gallery items |
|
|
Thanks for responding.
To clarify the main concern we are having is that people have bookmarked
resources such as a .pdf or .doc and now they are getting a 401 when
requesting the object. NOTE: The anonymous web user doesn’t know or should
care whether it is as a local or shared resource they are looking at.
The following is a list of some of the scenarios and their results:
1. A bookmark to a shared resource record will continue to function
independent of the posting which hosted the link. Reason: The resource link
contains a direct reference (GUID) to the resource record itself along with
other additional code flagging parameters. If you delete or purge the shared
resource record you get a 401.
2. A bookmark to a local resource record will continue to function so long
as the posting containing the link is published. A deleted or expired posting
returns the 401 and a purged posting returns a 404. Reason: The resource link
contains a reference to the posting (GUID) and then an additional parameter
used in a MCMS reference table to locate the resource.
3. Any URL typo in a resource record or posting root GUID produces a 404.
4. Any URL typo in a resource record immediately following the GUID produces
a 401.
These resources are not managed in the MCMS database directly, only a record
of reference is managed. Without the reference the file is useless and only
takes up space on the hard drive. So we are actually dealing with two issues:
1. Why not remove the physical resources when all their references are gone?
2. If we can't manipulate a resource any longer through the resource or site
manager interfaces then why serve a 401? The latter being the only pressing
issue.
It would make a bit more sense to say to a anonymous web user "the file
doesn't exist, because we have no record of it any longer in our MCMS
database (404)" than to say "the file may or may not exist, so log in to find
out (401) and then after you do that we will redirect you appropriately -
either to the file or to a 404.”
I just wanted to know if there is a fix for this. If MCMS was designed
without considering this or it is a known bug, that is fine. I’ll just hope
for a change in the next release and introduce a process around it now for
our content developers. Please advise.
Thanks
"florida225" wrote:
| Quote: | We are getting a similar situation as mentioned below in another thread, but
more specifically we want to know why MCMS doesn't just return a 404 error?
_________________________________________________________________
Hi Jake,
if a login prompt comes then the current user does not have rights on these
items.
Please verify if these items are in a resource gallery and ensure that
sufficient rights are assigned to this resource gallery.
If these are local attachments you need to ensure that the correct
permissions are given to the channel of the posting these attachments belong
to.
Another known reason for this behaviour is that this happens if these
attachments are resource gallery items which have been deleted.
The easiest way to resolve this would be to remove the references to the
deleted resources from the postings.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no rights
New to MCMS?
Check out this book: Building Websites Using MCMS: http://tinyurl.com/6zj44
----------------------
"Jake" <Jake@discussions.microsoft.com> wrote in message
news:9F010790-B847-4E15-AAEE-1328F6FC20D3@microsoft.com...
Our internal search engine has picked up pages on our CMS site that cannot
be
indexed. It states that access is denied. If I navigate to these pages
then I
get a Windows/IIS login box? I have noticed that all the pages are PDF
attachments and that there are being requested from /NR/rdonlyres/ which I
believe is part of the CMS cache.
|
|
|
| Back to top |
|
|
Stefan [MSFT]
Guest
|
| Posted:
Tue Oct 25, 2005 4:51 pm Post subject:
Re: 401 response on deleted resource gallery items |
|
|
Hi,
deleted resource gallery items will be removed from the database
automatically by background processing when no further reference to the
resource gallery item exists.
After removing the item a 404 - page not found will be returned rather than
a 401.
If a 401 is returned means that the items still references somewhere so that
background processing was not able to remove it.
Be aware that this also includes historical revisions of postings! So you
might need to purge the revision history to ensure that deleted resource
gallery items will be removed from the repository.
Even the physical resource will still be in the database! But it is now in a
special internal folder named "Archive Folder". So you won't see it in Site
Manager but it is still there.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no rights
New to MCMS?
Check out this book: Building Websites Using MCMS: http://tinyurl.com/6zj44
----------------------
"florida225" <florida225@discussions.microsoft.com> wrote in message
news:C2EA1A54-0C8C-4C4C-905C-EC83C46F859D@microsoft.com...
| Quote: | Thanks for responding.
To clarify the main concern we are having is that people have bookmarked
resources such as a .pdf or .doc and now they are getting a 401 when
requesting the object. NOTE: The anonymous web user doesn't know or should
care whether it is as a local or shared resource they are looking at.
The following is a list of some of the scenarios and their results:
1. A bookmark to a shared resource record will continue to function
independent of the posting which hosted the link. Reason: The resource
link
contains a direct reference (GUID) to the resource record itself along
with
other additional code flagging parameters. If you delete or purge the
shared
resource record you get a 401.
2. A bookmark to a local resource record will continue to function so long
as the posting containing the link is published. A deleted or expired
posting
returns the 401 and a purged posting returns a 404. Reason: The resource
link
contains a reference to the posting (GUID) and then an additional
parameter
used in a MCMS reference table to locate the resource.
3. Any URL typo in a resource record or posting root GUID produces a 404.
4. Any URL typo in a resource record immediately following the GUID
produces
a 401.
These resources are not managed in the MCMS database directly, only a
record
of reference is managed. Without the reference the file is useless and
only
takes up space on the hard drive. So we are actually dealing with two
issues:
1. Why not remove the physical resources when all their references are
gone?
2. If we can't manipulate a resource any longer through the resource or
site
manager interfaces then why serve a 401? The latter being the only
pressing
issue.
It would make a bit more sense to say to a anonymous web user "the file
doesn't exist, because we have no record of it any longer in our MCMS
database (404)" than to say "the file may or may not exist, so log in to
find
out (401) and then after you do that we will redirect you appropriately -
either to the file or to a 404."
I just wanted to know if there is a fix for this. If MCMS was designed
without considering this or it is a known bug, that is fine. I'll just
hope
for a change in the next release and introduce a process around it now for
our content developers. Please advise.
Thanks
"florida225" wrote:
We are getting a similar situation as mentioned below in another thread,
but
more specifically we want to know why MCMS doesn't just return a 404
error?
_________________________________________________________________
Hi Jake,
if a login prompt comes then the current user does not have rights on
these
items.
Please verify if these items are in a resource gallery and ensure that
sufficient rights are assigned to this resource gallery.
If these are local attachments you need to ensure that the correct
permissions are given to the channel of the posting these attachments
belong
to.
Another known reason for this behaviour is that this happens if these
attachments are resource gallery items which have been deleted.
The easiest way to resolve this would be to remove the references to the
deleted resources from the postings.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no
rights
New to MCMS?
Check out this book: Building Websites Using MCMS:
http://tinyurl.com/6zj44
----------------------
"Jake" <Jake@discussions.microsoft.com> wrote in message
news:9F010790-B847-4E15-AAEE-1328F6FC20D3@microsoft.com...
Our internal search engine has picked up pages on our CMS site that
cannot
be
indexed. It states that access is denied. If I navigate to these pages
then I
get a Windows/IIS login box? I have noticed that all the pages are PDF
attachments and that there are being requested from /NR/rdonlyres/
which I
believe is part of the CMS cache.
|
|
|
| Back to top |
|
|
Stefan [MSFT]
Guest
|
| Posted:
Wed Oct 26, 2005 8:51 am Post subject:
Re: 401 response on deleted resource gallery items |
|
|
Hi Doug,
about the background processing job steps, see here for details:
http://blogs.technet.com/stefan_gossner/archive/2005/06/08/406075.aspx
(step 5)
It is not possible to automate revision history purges. This can only be
done manually using Site Manager.
References to resources are stored in an internal format which is not
officially documented. In short words: this internal format allows to move
the item around in the resource galleries without a need to update the
placeholder content. It also allows to resource gallery items and references
in the placeholders will automatically be maintained - either dynamically
(to ensure that the update is working in the same moment) and also through a
background processing step to speed up this process later (step 3)
The last question would mean to give you information about the internals of
the MCMS database. Actually the database schema is not documented for the
public and direct access to the database would also break the Microsoft
Support Boundaries for MCMS - so even having this information would not help
you.
In addition the schema can and has changed without any notice when
installing service packs or hotfixes.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no rights
New to MCMS?
Check out this book: Building Websites Using MCMS: http://tinyurl.com/6zj44
----------------------
"Doug" <Doug@discussions.microsoft.com> wrote in message
news:A3571CC3-0C91-4896-A368-3189104F9C8F@microsoft.com...
| Quote: | Hi Stefan,
I work with florida255 and I have a few follow up questions regarding your
response.
Which of the background processing stored procedures is responsible for
removing deleted resource gallery items that no longer have a reference to
them? I would like to confirm that we have this stored procedure enabled
in
our BCP Job.
Is it possible to schedule/automate revision history purges? If we could
add
something to the existing BCP Job on our SLQ server, that would be great.
Our
production site is read only so automating this would be a big help in
addressing this issue as well as minimizing DB size.
How are references to resource gallery items maintained? How are
references
to resources that are uploaded through the "Insert Local Attachment"
dialog?
Best Regards,
Doug
"Stefan [MSFT]" wrote:
Hi,
deleted resource gallery items will be removed from the database
automatically by background processing when no further reference to the
resource gallery item exists.
After removing the item a 404 - page not found will be returned rather
than
a 401.
If a 401 is returned means that the items still references somewhere so
that
background processing was not able to remove it.
Be aware that this also includes historical revisions of postings! So you
might need to purge the revision history to ensure that deleted resource
gallery items will be removed from the repository.
Even the physical resource will still be in the database! But it is now
in a
special internal folder named "Archive Folder". So you won't see it in
Site
Manager but it is still there.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no
rights
New to MCMS?
Check out this book: Building Websites Using MCMS:
http://tinyurl.com/6zj44
----------------------
"florida225" <florida225@discussions.microsoft.com> wrote in message
news:C2EA1A54-0C8C-4C4C-905C-EC83C46F859D@microsoft.com...
Thanks for responding.
To clarify the main concern we are having is that people have
bookmarked
resources such as a .pdf or .doc and now they are getting a 401 when
requesting the object. NOTE: The anonymous web user doesn't know or
should
care whether it is as a local or shared resource they are looking at.
The following is a list of some of the scenarios and their results:
1. A bookmark to a shared resource record will continue to function
independent of the posting which hosted the link. Reason: The resource
link
contains a direct reference (GUID) to the resource record itself along
with
other additional code flagging parameters. If you delete or purge the
shared
resource record you get a 401.
2. A bookmark to a local resource record will continue to function so
long
as the posting containing the link is published. A deleted or expired
posting
returns the 401 and a purged posting returns a 404. Reason: The
resource
link
contains a reference to the posting (GUID) and then an additional
parameter
used in a MCMS reference table to locate the resource.
3. Any URL typo in a resource record or posting root GUID produces a
404.
4. Any URL typo in a resource record immediately following the GUID
produces
a 401.
These resources are not managed in the MCMS database directly, only a
record
of reference is managed. Without the reference the file is useless and
only
takes up space on the hard drive. So we are actually dealing with two
issues:
1. Why not remove the physical resources when all their references are
gone?
2. If we can't manipulate a resource any longer through the resource or
site
manager interfaces then why serve a 401? The latter being the only
pressing
issue.
It would make a bit more sense to say to a anonymous web user "the file
doesn't exist, because we have no record of it any longer in our MCMS
database (404)" than to say "the file may or may not exist, so log in
to
find
out (401) and then after you do that we will redirect you
appropriately -
either to the file or to a 404."
I just wanted to know if there is a fix for this. If MCMS was designed
without considering this or it is a known bug, that is fine. I'll just
hope
for a change in the next release and introduce a process around it now
for
our content developers. Please advise.
Thanks
"florida225" wrote:
We are getting a similar situation as mentioned below in another
thread,
but
more specifically we want to know why MCMS doesn't just return a 404
error?
_________________________________________________________________
Hi Jake,
if a login prompt comes then the current user does not have rights on
these
items.
Please verify if these items are in a resource gallery and ensure that
sufficient rights are assigned to this resource gallery.
If these are local attachments you need to ensure that the correct
permissions are given to the channel of the posting these attachments
belong
to.
Another known reason for this behaviour is that this happens if these
attachments are resource gallery items which have been deleted.
The easiest way to resolve this would be to remove the references to
the
deleted resources from the postings.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no
rights
New to MCMS?
Check out this book: Building Websites Using MCMS:
http://tinyurl.com/6zj44
----------------------
"Jake" <Jake@discussions.microsoft.com> wrote in message
news:9F010790-B847-4E15-AAEE-1328F6FC20D3@microsoft.com...
Our internal search engine has picked up pages on our CMS site that
cannot
be
indexed. It states that access is denied. If I navigate to these
pages
then I
get a Windows/IIS login box? I have noticed that all the pages are
PDF
attachments and that there are being requested from /NR/rdonlyres/
which I
believe is part of the CMS cache.
|
|
|
| Back to top |
|
|
Doug
Guest
|
| Posted:
Wed Oct 26, 2005 4:51 pm Post subject:
Re: 401 response on deleted resource gallery items |
|
|
Hi Stefan,
Thanks for the additional info. It was very helpfull.
One last question.
Is there any way to determine what reference might exist to a deleted
resouce gallery item or even any resource gallery item, regardless of if it
has been deleted or not? (Similar to the dependent report for templates.)
Thanks,
Doug
"Stefan [MSFT]" wrote:
| Quote: | Hi Doug,
about the background processing job steps, see here for details:
http://blogs.technet.com/stefan_gossner/archive/2005/06/08/406075.aspx
(step 5)
It is not possible to automate revision history purges. This can only be
done manually using Site Manager.
References to resources are stored in an internal format which is not
officially documented. In short words: this internal format allows to move
the item around in the resource galleries without a need to update the
placeholder content. It also allows to resource gallery items and references
in the placeholders will automatically be maintained - either dynamically
(to ensure that the update is working in the same moment) and also through a
background processing step to speed up this process later (step 3)
The last question would mean to give you information about the internals of
the MCMS database. Actually the database schema is not documented for the
public and direct access to the database would also break the Microsoft
Support Boundaries for MCMS - so even having this information would not help
you.
In addition the schema can and has changed without any notice when
installing service packs or hotfixes.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no rights
New to MCMS?
Check out this book: Building Websites Using MCMS: http://tinyurl.com/6zj44
----------------------
"Doug" <Doug@discussions.microsoft.com> wrote in message
news:A3571CC3-0C91-4896-A368-3189104F9C8F@microsoft.com...
Hi Stefan,
I work with florida255 and I have a few follow up questions regarding your
response.
Which of the background processing stored procedures is responsible for
removing deleted resource gallery items that no longer have a reference to
them? I would like to confirm that we have this stored procedure enabled
in
our BCP Job.
Is it possible to schedule/automate revision history purges? If we could
add
something to the existing BCP Job on our SLQ server, that would be great.
Our
production site is read only so automating this would be a big help in
addressing this issue as well as minimizing DB size.
How are references to resource gallery items maintained? How are
references
to resources that are uploaded through the "Insert Local Attachment"
dialog?
Best Regards,
Doug
"Stefan [MSFT]" wrote:
Hi,
deleted resource gallery items will be removed from the database
automatically by background processing when no further reference to the
resource gallery item exists.
After removing the item a 404 - page not found will be returned rather
than
a 401.
If a 401 is returned means that the items still references somewhere so
that
background processing was not able to remove it.
Be aware that this also includes historical revisions of postings! So you
might need to purge the revision history to ensure that deleted resource
gallery items will be removed from the repository.
Even the physical resource will still be in the database! But it is now
in a
special internal folder named "Archive Folder". So you won't see it in
Site
Manager but it is still there.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no
rights
New to MCMS?
Check out this book: Building Websites Using MCMS:
http://tinyurl.com/6zj44
----------------------
"florida225" <florida225@discussions.microsoft.com> wrote in message
news:C2EA1A54-0C8C-4C4C-905C-EC83C46F859D@microsoft.com...
Thanks for responding.
To clarify the main concern we are having is that people have
bookmarked
resources such as a .pdf or .doc and now they are getting a 401 when
requesting the object. NOTE: The anonymous web user doesn't know or
should
care whether it is as a local or shared resource they are looking at.
The following is a list of some of the scenarios and their results:
1. A bookmark to a shared resource record will continue to function
independent of the posting which hosted the link. Reason: The resource
link
contains a direct reference (GUID) to the resource record itself along
with
other additional code flagging parameters. If you delete or purge the
shared
resource record you get a 401.
2. A bookmark to a local resource record will continue to function so
long
as the posting containing the link is published. A deleted or expired
posting
returns the 401 and a purged posting returns a 404. Reason: The
resource
link
contains a reference to the posting (GUID) and then an additional
parameter
used in a MCMS reference table to locate the resource.
3. Any URL typo in a resource record or posting root GUID produces a
404.
4. Any URL typo in a resource record immediately following the GUID
produces
a 401.
These resources are not managed in the MCMS database directly, only a
record
of reference is managed. Without the reference the file is useless and
only
takes up space on the hard drive. So we are actually dealing with two
issues:
1. Why not remove the physical resources when all their references are
gone?
2. If we can't manipulate a resource any longer through the resource or
site
manager interfaces then why serve a 401? The latter being the only
pressing
issue.
It would make a bit more sense to say to a anonymous web user "the file
doesn't exist, because we have no record of it any longer in our MCMS
database (404)" than to say "the file may or may not exist, so log in
to
find
out (401) and then after you do that we will redirect you
appropriately -
either to the file or to a 404."
I just wanted to know if there is a fix for this. If MCMS was designed
without considering this or it is a known bug, that is fine. I'll just
hope
for a change in the next release and introduce a process around it now
for
our content developers. Please advise.
Thanks
"florida225" wrote:
We are getting a similar situation as mentioned below in another
thread,
but
more specifically we want to know why MCMS doesn't just return a 404
error?
_________________________________________________________________
Hi Jake,
if a login prompt comes then the current user does not have rights on
these
items.
Please verify if these items are in a resource gallery and ensure that
sufficient rights are assigned to this resource gallery.
If these are local attachments you need to ensure that the correct
permissions are given to the channel of the posting these attachments
belong
to.
Another known reason for this behaviour is that this happens if these
attachments are resource gallery items which have been deleted.
The easiest way to resolve this would be to remove the references to
the
deleted resources from the postings.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no
rights
New to MCMS?
Check out this book: Building Websites Using MCMS:
http://tinyurl.com/6zj44
----------------------
"Jake" <Jake@discussions.microsoft.com> wrote in message
news:9F010790-B847-4E15-AAEE-1328F6FC20D3@microsoft.com...
Our internal search engine has picked up pages on our CMS site that
cannot
be
indexed. It states that access is denied. If I navigate to these
pages
then I
get a Windows/IIS login box? I have noticed that all the pages are
PDF
attachments and that there are being requested from /NR/rdonlyres/
which I
believe is part of the CMS cache.
|
|
|
| Back to top |
|
|
Stefan [MSFT]
Guest
|
| Posted:
Wed Oct 26, 2005 8:51 pm Post subject:
Re: 401 response on deleted resource gallery items |
|
|
Hi Doug,
unfortunatelly MCMS does not provide documented methods to get this info
automatically.
You could enumerate all placeholders in all revisions of all postings in all
channels and search for a link to the resource.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no rights
New to MCMS?
Check out this book: Building Websites Using MCMS: http://tinyurl.com/6zj44
----------------------
"Doug" <Doug@discussions.microsoft.com> wrote in message
news:A69535B8-EF5C-4987-AB91-1899C969333B@microsoft.com...
| Quote: | Hi Stefan,
Thanks for the additional info. It was very helpfull.
One last question.
Is there any way to determine what reference might exist to a deleted
resouce gallery item or even any resource gallery item, regardless of if
it
has been deleted or not? (Similar to the dependent report for templates.)
Thanks,
Doug
"Stefan [MSFT]" wrote:
Hi Doug,
about the background processing job steps, see here for details:
http://blogs.technet.com/stefan_gossner/archive/2005/06/08/406075.aspx
(step 5)
It is not possible to automate revision history purges. This can only be
done manually using Site Manager.
References to resources are stored in an internal format which is not
officially documented. In short words: this internal format allows to
move
the item around in the resource galleries without a need to update the
placeholder content. It also allows to resource gallery items and
references
in the placeholders will automatically be maintained - either dynamically
(to ensure that the update is working in the same moment) and also
through a
background processing step to speed up this process later (step 3)
The last question would mean to give you information about the internals
of
the MCMS database. Actually the database schema is not documented for the
public and direct access to the database would also break the Microsoft
Support Boundaries for MCMS - so even having this information would not
help
you.
In addition the schema can and has changed without any notice when
installing service packs or hotfixes.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no
rights
New to MCMS?
Check out this book: Building Websites Using MCMS:
http://tinyurl.com/6zj44
----------------------
"Doug" <Doug@discussions.microsoft.com> wrote in message
news:A3571CC3-0C91-4896-A368-3189104F9C8F@microsoft.com...
Hi Stefan,
I work with florida255 and I have a few follow up questions regarding
your
response.
Which of the background processing stored procedures is responsible for
removing deleted resource gallery items that no longer have a reference
to
them? I would like to confirm that we have this stored procedure
enabled
in
our BCP Job.
Is it possible to schedule/automate revision history purges? If we
could
add
something to the existing BCP Job on our SLQ server, that would be
great.
Our
production site is read only so automating this would be a big help in
addressing this issue as well as minimizing DB size.
How are references to resource gallery items maintained? How are
references
to resources that are uploaded through the "Insert Local Attachment"
dialog?
Best Regards,
Doug
"Stefan [MSFT]" wrote:
Hi,
deleted resource gallery items will be removed from the database
automatically by background processing when no further reference to
the
resource gallery item exists.
After removing the item a 404 - page not found will be returned rather
than
a 401.
If a 401 is returned means that the items still references somewhere
so
that
background processing was not able to remove it.
Be aware that this also includes historical revisions of postings! So
you
might need to purge the revision history to ensure that deleted
resource
gallery items will be removed from the repository.
Even the physical resource will still be in the database! But it is
now
in a
special internal folder named "Archive Folder". So you won't see it in
Site
Manager but it is still there.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no
rights
New to MCMS?
Check out this book: Building Websites Using MCMS:
http://tinyurl.com/6zj44
----------------------
"florida225" <florida225@discussions.microsoft.com> wrote in message
news:C2EA1A54-0C8C-4C4C-905C-EC83C46F859D@microsoft.com...
Thanks for responding.
To clarify the main concern we are having is that people have
bookmarked
resources such as a .pdf or .doc and now they are getting a 401 when
requesting the object. NOTE: The anonymous web user doesn't know or
should
care whether it is as a local or shared resource they are looking
at.
The following is a list of some of the scenarios and their results:
1. A bookmark to a shared resource record will continue to function
independent of the posting which hosted the link. Reason: The
resource
link
contains a direct reference (GUID) to the resource record itself
along
with
other additional code flagging parameters. If you delete or purge
the
shared
resource record you get a 401.
2. A bookmark to a local resource record will continue to function
so
long
as the posting containing the link is published. A deleted or
expired
posting
returns the 401 and a purged posting returns a 404. Reason: The
resource
link
contains a reference to the posting (GUID) and then an additional
parameter
used in a MCMS reference table to locate the resource.
3. Any URL typo in a resource record or posting root GUID produces a
404.
4. Any URL typo in a resource record immediately following the GUID
produces
a 401.
These resources are not managed in the MCMS database directly, only
a
record
of reference is managed. Without the reference the file is useless
and
only
takes up space on the hard drive. So we are actually dealing with
two
issues:
1. Why not remove the physical resources when all their references
are
gone?
2. If we can't manipulate a resource any longer through the resource
or
site
manager interfaces then why serve a 401? The latter being the only
pressing
issue.
It would make a bit more sense to say to a anonymous web user "the
file
doesn't exist, because we have no record of it any longer in our
MCMS
database (404)" than to say "the file may or may not exist, so log
in
to
find
out (401) and then after you do that we will redirect you
appropriately -
either to the file or to a 404."
I just wanted to know if there is a fix for this. If MCMS was
designed
without considering this or it is a known bug, that is fine. I'll
just
hope
for a change in the next release and introduce a process around it
now
for
our content developers. Please advise.
Thanks
"florida225" wrote:
We are getting a similar situation as mentioned below in another
thread,
but
more specifically we want to know why MCMS doesn't just return a
404
error?
_________________________________________________________________
Hi Jake,
if a login prompt comes then the current user does not have rights
on
these
items.
Please verify if these items are in a resource gallery and ensure
that
sufficient rights are assigned to this resource gallery.
If these are local attachments you need to ensure that the correct
permissions are given to the channel of the posting these
attachments
belong
to.
Another known reason for this behaviour is that this happens if
these
attachments are resource gallery items which have been deleted.
The easiest way to resolve this would be to remove the references
to
the
deleted resources from the postings.
Cheers,
Stefan
--
This posting is provided "AS IS" with no warranties, and confers no
rights
New to MCMS?
Check out this book: Building Websites Using MCMS:
http://tinyurl.com/6zj44
----------------------
"Jake" <Jake@discussions.microsoft.com> wrote in message
news:9F010790-B847-4E15-AAEE-1328F6FC20D3@microsoft.com...
Our internal search engine has picked up pages on our CMS site
that
cannot
be
indexed. It states that access is denied. If I navigate to these
pages
then I
get a Windows/IIS login box? I have noticed that all the pages
are
PDF
attachments and that there are being requested from
/NR/rdonlyres/
which I
believe is part of the CMS cache.
|
|
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in