I found a solution, It was actually caused by the setting the property simple to true in the ProtectedPage method i invoked before doing the stuff in my previous post.
This was the code i tried, which didn't work properly:
Access.ProtectPage(true, document.Id, 0, 0);
This was the code that made it work:
Access.ProtectPage(false, document.Id, 0, 0);
No more errors on the public access page after this fix.
In case anyone else does this, and finds Access.ProtectPage() is obsolete, the equivalent way of doing it using the PublicAccessService is as follows.
var registrationPage = ApplicationContext.Current.Services.ContentService.GetById(MYID);
var pageToRestrictAccessTo= ApplicationContext.Current.Services.ContentService.GetById(MYID);
var entry = new PublicAccessEntry(pageToRestrictAccessTo, registrationPage, registrationPage, new List<PublicAccessRule>());
ApplicationContext.Current.Services.PublicAccessService.Save(entry);
I've attempted to adapt this to Umbraco 8... but it shanks it so badly you have to restore the database to recover from the dreaded "Value cannot be null.
Parameter name: source"
What is wrong with this code?
var registrationPage = Services.ContentService.GetById(1234);
var pageToRestrictAccessTo = Services.ContentService.GetById(5678);
var entry = new PublicAccessEntry(pageToRestrictAccessTo, registrationPage, registrationPage, new List<PublicAccessRule>());
Services.PublicAccessService.Save(entry);
Note that I am using a surface controller - I haven't made it as far as adding a rule yet because it wigs out before that, imagine it will be something like
For Umbraco 8, I found this worked (accessRestrictions is just a list of member role names):
var memberRoleAccessRules = accessRestrictions.Select(x => new PublicAccessRule() { RuleType = "MemberRole", RuleValue = x });
_publicAccessService.Save(new PublicAccessEntry(protectedNode, loginNode, noAccessNode, memberRoleAccessRules));
Note: I also faced the same errors as above and corrupted the DB when following the above example (found elsewhere). The DB corruption stems from an UmbracoAccess entry that has no UmbracoAccessRules and can be undone by removing the offending rows from the following DB table:
DELETE FROM [umbracoAccess] WHERE nodeId = <ID of the node you tried to protect when you broke everything>
Or just leave the WHERE off the query if you're happy to nuke all the rules (you may also need to DELETE FROM [umbracoAccessRule] first when doing a full nuke)
Programmatically add Public Access to document
Hi,
Which API do I need to use if i want to add Public Access, i.e. a member group to a specific document/node programmatically?
Currently I do like this:
...and it works, except that it throws an exception in the backoffice which is not good, I guess?
Document doesn't contain a memberId. This might be caused if document is protected using umbraco RC1 or older.
I tried to use this method but it is deprecated:
Please help me out.
EDIT: I'm using version 7.2.2.
Best Regards,
Hampus Holmström
I found a solution, It was actually caused by the setting the property simple to true in the ProtectedPage method i invoked before doing the stuff in my previous post.
This was the code i tried, which didn't work properly:
This was the code that made it work:
No more errors on the public access page after this fix.
Best Regards,
Hampus
In case anyone else does this, and finds Access.ProtectPage() is obsolete, the equivalent way of doing it using the PublicAccessService is as follows.
And then to add a specific role
I've attempted to adapt this to Umbraco 8... but it shanks it so badly you have to restore the database to recover from the dreaded "Value cannot be null. Parameter name: source"
What is wrong with this code?
Note that I am using a surface controller - I haven't made it as far as adding a rule yet because it wigs out before that, imagine it will be something like
For Umbraco 8, I found this worked (accessRestrictions is just a list of member role names):
Note: I also faced the same errors as above and corrupted the DB when following the above example (found elsewhere). The DB corruption stems from an UmbracoAccess entry that has no UmbracoAccessRules and can be undone by removing the offending rows from the following DB table:
Or just leave the WHERE off the query if you're happy to nuke all the rules (you may also need to DELETE FROM [umbracoAccessRule] first when doing a full nuke)
is working on a reply...