Community Password

Thanks Susan !

However, I have the [DocPassword] working but fail because of an entirely different problem;
as it occured while implementing this feature I bring it up here, but realise it should prolly be in a different forum (? plse advise)

in an earlier unattended moment I checked the XHTML URLs ’Yes’-button and after many sighs&moaning found the editor kept changing the ampersands in the code while implementing the [DocPassword] snippetcall on my new unauthorised-page and consequently the form-chunk didn’t show up.
it does show when called as a chunk on its own so it must be the addressing which was confirmed by the ’&’-thingy showing up in the browser’s addressline.
(which may represent another problem; it shows the id of the protected page..?)

now the problem: checking the ’No’-button in the configuration resulted in a message: ’Failed to update setting value!’,
plus although the ’No’ is checked in the configurationpage now, upon saving edited pages the system keeps changing the ampersands in the infamous ’&’
and consequently I cannot get my new unauthorised-page to show the form-chunk.

is there something wrong with the XHTML URLs thing or in the configuration?
where should I look?
lmv

checking the database I find:

friendly_urls 0
friendly_url_prefix (empty)
friendly_url_suffix .html
friendly_alias_urls 1
use_alias_path 0

somehow the configuration-editor did not change friendly_alias_urls?
but it shows ’No’-button checked in the page

changing it directly in the database to 0 does not make the phenomenon go away; ampersands are changed into ’&amps;’.

<sigh> I trust this is something that’ll make me blush when I get it explained..
lmv

<sigh>&<blush>

remembering the above ’whitespace-issue’ when copying from browsers etc., I removed all spaces and retyped the call;

and it (DocPassword) now works...

I stand corrected and apol. for time taken
lmv

but wishing all a fine weekend !

Indeed, I’ve had copy/paste from a browser fail because of fancy quote marks in the text being copied!

I have to build community sites all of the time.

My suggestion is make the people sign up and login. In the end it will be MUCH easier to deal with.

I am currently building a site when the users log in a completely different and unique site is presented based on their privileges ( at the same domain). The entire public site is removed until they log out.

Anyone getting a hold of the printed copy would indeed be able to get access to your content anyway. If the content doesn’t matter enough to have better security on it then that, then why is there a password in the first place?

(why anyone would print a publication anymore is beyond me -- paper is dead)

Quote from: lmv at Jan 05, 2008, 02:34 AM

[DocPassword] snippetcall on my new unauthorised-page and consequently the form-chunk didn’t show up.

....

and consequently I cannot get my new unauthorised-page to show the form-chunk.

...
is there something wrong with the XHTML URLs thing or in the configuration?

lmv

@lmv,

On your unauthorized-page, the form will not show up unless it has the &unauthid parameter present in your HTTP request (GET/POST) [e.g. in the query string as I stated above)
]

If you browse to your unauth page, passing &unauthid=25 (where 25 is the protected doc_id with your content) the form will then display, as it now nows which doc_id to authenticate against. Upon successful authentication, the user is directed to doc_id 25, with content revealed. If it was set up so that the form showed up every time (even without the presence of unauthid), DocPassword would not know which document to check the submitted password for. Does that make sense?

Anyhow, I saw that you did have everything working, hopefully all is well now? Best of luck!

Thanks Mike for yr constructive attitude, it beats the h. out of opinions (which are defensive anyway).

unfortunately my life is dictated by reality, the world seems to want things irrespective of what I think about it..

but ’conditional redirecting’, what a beautifull concept!

up to a point I understand it and have the DocPassword working on pages I want to shield off and it redirects nicely to my own-made unauthorized page where the form is shown and so on.

But like most people I’m lazy and don’t want to understand the brilliance behind solutions like yours, nor how they work or are designed.
Shame on me. I just want to copy & paste and follow instructions written for children and get what I want without further thinking.

I admit my weakness, but I hope you’ll bear with me a bit more (as it may help others as well..) and I did spent a lot of time on it.


Through the (Wayfinder-) menu they arrive at what I call the entry-page(48), where they get explained they need to give the password and...
should find the form. Only after completing that they can arrive at the protected page (54 btw).
and to avoid registering several hundreds of members that only check in to see the agenda etc. this should be done by single password only.
(no username registration)
In your concept they only get the form when they attempt to go to a restricted page and are relayed to the systemsnonauthorised page(77).

So to get the form on it I’ve been DocPassword-protecting my entry-page (48) (which can even be made to redirect to itself and show in stead of the systems-unauthorised-page), but it then doesn’t show the inputform.

I may have been trying to hard to understand your beautifull solution and overlook the big picture ?
or we’re on different scenario-tracks.
lmv

I don’t think the protected page page and unauthorized page (login form) can be the same. (At least I didn’t think so...) Unless I am misunderstanding what you’ve said...

<smile> yes ! there is a misunderstanding.. I think
the difference is: when do you see the form to give the password ?

in our concept we want the form before we link to the protected page on an unprotected explanatory page;
the webuser fills in the password there and.. is then transferred/allowed into the protected page.

DocPassword -as I understand it- protects the page when (read after) you try to go to it and then
thanks to DocPassword transfers you to your (or the) system’s unauthorised-page and where the form is presented
and after which you are then transferred to the protected page.

Effectively this means an extra step or two, but DocPassword has still great potential and use because it does provide the possibility to protect any of your pages against accidental entry.

A priceless addition would be if webusers that join in this fashion could be automatically added to a webuser-group so then the otherwise kept-hidden menu’s etc. will show and the children’s-protection-issue is solved at once.

Reading this back it suddenly occurs to me having dug into DocPassword so much as an amateur that doesn’t know what he’s looking at, that maybe all that’s needed is an additional chunk for DocPassword with the appropriate code in it such that Dombo’s as me only have to fill in the protected page-id in that and place it on any page.
lmv

Quote from: lmv at Jan 06, 2008, 07:45 AM

in our concept we want the form before we link to the protected page on an unprotected explanatory page;
the webuser fills in the password there and.. is then transferred/allowed into the protected page.

You should be able to accomplish exactly that. That said, how should DocPassword (your explanatory page) know what page to "redirect" to upon entering a correct password if you don’t tell it?

1. Make your custom unauthorized page, placing the DocPassword snippet call (w/ &redirect=`[*id*]`)

This should allow the page to be displayed without problem, where you can place any Explanatory text you want. However, at this point, there would be no form present.

2. To enable the form, you’ll need to tell your "explanatory" page what protected page to authenticate against. (redirect to) You accomplish this by passing the ?unauthid=modx_doc_id in your HTTP request. (GET or POST)

Basically, you can treat your explanatory page as an "entry page", you just have to tell it where to go. Otherwise, the form will cannot be displayed.

Say you always wanted it to go to the most recent month’s content, write a snippet to determine that month’s page’s doc_id and feed it into your Wayfinder call (placeholder), else build an alternate way to select which "protected" pages to navigate to so that the DocPassword has a document to compare the submitted password against.