Hi Roberto,
I know exactly what your problem is, I don't have a solution but I can tell you the history of it and maybe that will help us get to a solution.
When dotLRN was delivered to Sloan last year I did a lot of bug fixing to get it ready for launch. One of the bugs was there was no membership check on any page that displayed community content except the portal. So if someone url hacked, or if one user forwarded another a notification with urls linking directly to say a page in forums, that user was able to see the forum message even if they were not a member of that community.
Obviously this was unacceptable, and the obvious solution seemed to be to require community membership to read a class or any package mounted under it.
This fix lead to one immediate problem. You could no longer use the register page of the community you wanted to join, because since you weren't a member yet, you couldn't view it. The simple fix to that was to pass the community_id to the register page of dotLRN package you were currently in rather then the one you wanted to join.
The second problem I didn't find for 6 months when I tried to create public portals and found the same code Ben Bytheway found and ran into the same problem you did. I don't see how the public portals can work with the permission set up currently on dotLRN.
One thing you should be aware of is that the public portal code has never been used so even without the permissions settings it may not work. You should coordinate with the people contemplating a portals rewrite and see if they are even planning on keeping it.
It's possible that an analogous solution to the register page might work. You might be able to set up the dotLRN pages to take a portal_id and then use the dotLRN package one level up to display the community's public portal.
I didn't try this because the problem I was trying to solve for Sloan was slightly different then what you are trying to do. I wanted to replace the uninformative Security Violation page at any url within a community with a page customized for each community that gave a link to join that community if the user had permission to join (i.e. the community is open and the user is a full access user). Thus if someone is following a link from a forwarded notification to a forum message of a community they are not a member of a useful and informative page is displayed. I never found a way to do that without hacking the request processor and it was a "nice-to-have" feature not a requirement so it was never implemented.
