I converted one of my solution to Orchard 1.4.1 with proper database.
Q1: Whenever I run or goto any link by clicking menu item then it always hits to AccountController/AccessDenied method of Orchard.Users. why?
Q2: How to resolve this?
Please help
There are two scenarios in which this may happen:
You updated from 1.3 (or older) versions to 1.4.1. If that's the case - check the 1.4 upgrade information. EDIT: Actually this is probably not your case - you would get 404's, not AccessDenied, in this scenario.
You are using the source code from recent 1.x development branch. There is a new module in the works that will allow to restrict visibility of certain pages to specific users. If that's the case - go to admin screen and assign Page "View" permissions to Anonymous role.
Related
I'm using collective.sendaspdf for pdf download of plone pages, but it asks users to login whene they download a public content.
This appears strange as it happens just in the production server, not in the development server (the only difference seems that the latter is started in foreground mode).
Of course I can't assign particular permissions on objects to anonymous users, so I guess the problem is somewhere else
thanks to Jean's suggestion, i enabled the verbose security and the error is "Unauthorized: You are not allowed to access '##at_base_edit_view' in this context"
This looks strange to me as the page is the view of my content-type archetype-based, and it is published so it is visible to anonymous users. I repeat also that I have the development server with the same software installed where the authorization is correctly given, i.e. the page can be downloaded by anyone without login...what changes is the network configuration (I have an apache that performs some url rewriting in front of my zope server, but this just affects the path of the plone site to be hidden)
I wonder if I can manage to correct this just through the sendaspdf configuration. I don't know which additional info I could provide about the environment/configuration. I'm running Plone 4.0.4 + collective.sendaspdf 2.0
Ok, the problem was due to a bug in how collective.sendaspdf handles archetype-based content types, it's possible to workaround it by replacing the code:
view_name = context_type.getProperty('immediate_view')
with
view_name = context_type.getProperty('default_view')
in the method get_page_source of base.py, or by waiting the next release of the product.
I want to allow access to certain content to certain users for a limited time,
using a 'Dynamic Role' in Plone 3 ( http://collective-docs.readthedocs.org/en/latest/security/dynamic_roles.html ).
To this end I've created an add-on with a copy paste of example code - except that for now getDummyRolesOnContext() always returns my role.
But Plone never calls, or instanciates my DummyLocalRoleAdapter, and obviously my users never get the role assigned.
Here's what I know so far:
My dynamic role is defined in a rolemap.xml and get's created upon add-on installation.
My add-on is being imported - an exception on it's first line prevents Zope from starting
None of DummyLocalRoleAdapter are being called - I've spiked all of them with warnings and exceptions.
The adapter does get registered.
How do I continue debugging this - what's the magic part I'm missing?
Thanks!
My guess is that you need to somehow activate borg.localprole PAS plug-in in acl_users:
https://github.com/plone/borg.localrole/blob/master/borg/localrole/utils.py
There might have been borg.localrole add-on installer entry in the past, but now there doesn't seem to be one. My guess is that you need to call the actions from borg.localrole add-on setup code manually in your own add-on.
acl_users when borg.localroles is correctly installed:
When I first created my Plone (4.1) site, I made a mysite.policy add-on to include some custom users and a custom workflow.
I need to make some corrections to both the workflow and the permissions. I updated the src to include these changes, but updating the package in through the Plone add-on manager (uninstall - install) does not work. As soon as I uninstall the status of all my entries switches to "local policy", so I cannot get the fine-grained status setttings back when I reinstall.
Also, the user permissions do not seem to change. Possibly because they were already created at set-up of the site. But I cannot figure out how to code a change to permissions versus a setup of permissions in the rolemap.xml. I assumed that whatever is in that xml is what rules my plone world, but that does not seem to be working.
So far I cannot find anything about this in the manuals and books I have at hand. Any hints how to solve this? Perhaps the only way to go about this is a series of manual changes through ZMI, but it is so much less elegant to do it that wat.
There's plenty of options. I'll try to describe a couple of them.
If your changes include only changes in Generic Setup profile of your site policy (./src/my/site/policy/profile/default/-files) and you don't want to automate the upgrade, you could simply update the profile-files and re-run those specific import steps for your policy:
Open ZMI (site/manage) for your site and look for portal_setup.
Select Import-tab when on portal_setup.
Select the profile of your site policy from Select Profile or Snapshot-list (the title of your profile is defined by the registerProfile-directive in configure.zcml or profiles.zcml of your policy product).
Click to select import steps for Role / Permission Map and Workflow Tool.
From the bottom of the page, deselect Include dependencies.
Click Import selected steps-button.
Go to portal_workflow-tool on ZMI and Update security settings, if your workflow update should modify permission in existing workflow states.
These steps should re-import only the selected import steps of you site policy product's Generic Setup -profile. Re-importing individual steps this way should be quite safe, but be careful: accidental clicks at portal_setup screens may have unpredictable consequences.
These steps can also be automated by defining something called Generic Setup Upgrade Step.
I hope that the default Generic Setup -profile of your site policy product includes metadata.xml with line <version>1</version>.
Update that line to <version>2</version>.
Open the zcml-file with registerProfile-directive and, after it, add
<genericsetup:upgradeDepends
source="1" destination="2" sortkey="1"
title="Upgrade my.site.policy (1 to 2)"
description="Upgrades my.site.policy's default profile from version version 1 to 2."
profile="my.site.policy:default"
import_steps="rolemap workflow"
run_deps="false"
/>
These steps should register such an upgrade step from the profile version 1 to 2, which re-imports steps rolemap and workflow (rolemap.xml and workflows.xml). You should be able to run the upgrade step from the Plone Site Setup's Add-ons-screen, where there should now be an upgrade button after your installed policy product.
As mentioned by #toutpt, the Collective Developer Manual has more examples on upgrade steps. If you have ever wondered, why it's recommended to use integers in metadata.xml, usually independently from the product's release version number', this is the reason :).
Any changes that need upgrade must be shown by increment the number in profile/default/metadata.xml (keep integer). Next you have to write an upgrade step. It will add an upgrade button in the addons control panel.
Please follow this tutorial to learn how to create an upgrade step: http://collective-docs.readthedocs.org/en/latest/components/genericsetup.html?highlight=upgradestep#upgrade-steps
So I have an umbraco setup with a 'content' root node and then a 'home' node under that. Under the 'home' node is the content and the URLs are the name of those nodes for example I have a 'about u's node under home and it's URL is '/about-us/'
In the case of the 'news' node, below 'about us', its children some times get '/home/about-us/news/title' of the story as the URL, which throws a 404. I can see that this is the URL of the node on the properties tab, but if I republish it it returns to '/about-us/news/title' for a period before returning to the broken link.
I have only seen this behavior on this node, which contains new-item document types. I basically watched the umbraco tv video and created it following along.
It seems to be to be a umbraco bug, but I would really appreciate any help with the issue
In the web.config, there is a setting called umbracoHideTopLevelNodeFromPath. This causes the behavior you are describing when it is set to false. Do you perhaps have multiple people working on the site and publishing different versions of the web.config that have this setting changed?
When publishing a node with the setting set to false, it would add the /home part to the URL. Otherwise, it would leave off the /home.
Once the Umbraco application has started, there are several processes that run on a regular basis (e.g. to check for expired content). It is possible to piggy-back on these by creating a custom class that inherits from umbraco.cms.businesslogic.ApplicationBase. If you have created one that uses the Document.AfterPublish eventhandler then I would check that it is not causing the issue.
I'm assuming that you haven't written one of these though, so the only other thing I can suggest is checking whether it is an installed package that is causing the issue. Have you installed any Umbraco packages? If so, do they have any automated behaviours, like creating folders etc. If so, this may be causing the issue. The author of a package will usually have a website, codeplex project etc. and they will usually have a issue list or blog.
Edit
I've just quickly checked and uBlogsy, one of the plugins you mention exactly this. It has auto moving and sorting of posts. This is described in the release notes. If you are using this tool for creating news pages, then this will be your issue.
I followed obsidian's link in his answer and read about someone else having the same issue. It seems to be traces back to a umbraco.library:NiceUrlFullPath call in the RSS creator that was feeding news items. I replaced the umbraco.library:NiceUrlFullPath calls with umbraco.library:NiceUrl calls and the issue has disappeared.
Please see my DNN Forum Post for more details.
I've never had any issues with DotNetNuke installations. But with the new v5.20 (or v5.02, whichever it really is), everything runs perfectly fine through installation. I then get to the main default portal homepage. But as soon as I click any of the links available to continue (Home, Register or Login) I get 404 errors every time with a reference back to the applicable aspx page (Home.aspx, Register.aspx or Login.aspx.).
Windows 7, IIS7, SQL Server 2008. All permissions are setup properly on the directory and in IIS. I would think this is an IIS7 configuration issue, but I've tweaked everything in there a half-dozen times. No one at DNN is returning answers on my forum post anymore either after one guy tried.
Help!
This is something to do with the Friendly URL stuff. I found this blog post which talks about the Friendly URL Provider architecture. This made me try changing the urlFormat attribute for the DNNFriendlyUrl provider from "humanfriendly" to "searchfriendly", which made the URLs the way they used to be. I'm not sure exactly where things are going wrong and don't really have time to dig into it at the moment, but hopefully this will be helpful to get you moving again too.
With the release of DNN5 (up until 5.02.01 as of the time of writing), the friendly URL provider won't work when DotNetNuke is not on default port 80. There are different solutions floating around, but the simplest is just to replace the DNN friendly URL provider with the free one from iFinity. The installation is really simple and included in the download. Or see the following blog post:
http://www.sailer.com.au/dotnetnuke/dnn5-friendlyurl-port
Okay have you tried the 'old style' of login - domain.com/default.aspx?ctl=login
If that still doesnt work then i have to say that most likely something has happened to IIS - if so then you might just see if you can install the package you have on a different box or have a friend try a different box
I have done 2 upgrades with 5.2 and a few test installs with the Starter Kit Package and Install packages and have never seen this problem - not to say that it doesnt exist.
My next trial would be to go and redownload the install package from CodePlex and start from scratch to see if you can make the same thing happen again.
OKayone thing I dont think that has been mentioned in reading through everything is double check IIS.
My first guess without looking on your server would be to check if something happened to the 'check file exists' setting - i know this is changed in IIS7 so I cant point to the exact place to check this.
Here is a link to the IIS7 forums on it - http://forums.iis.net/t/1092696.aspx
http://forums.asp.net/t/1191083.aspx
either one might help - google also has a lot on this
Tell me how this goes in checking up on it and we can move forward from there!
you probably need to reg_iis on the version(s) of asp.net that your IIS is going to support.
http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
If the right version is not set up then you will get the 404 error
So placing it under port 80 works, right?
Is there a good reason not putting it under that port?