New Foswiki release 2.1.6 is available with important security fixes.
Sourceforge foswiki email lists being discontinued. Subscribe to the new Foswiki announce and discuss lists at MailingLists
This question about Using an extension: Answered

Login form instead of list of attachments

Hi there,

I installed topicinteraction plugin, metacomment and so on. It works fine when I login to my foswiki, but if I am not logged in, I do not see the list of attachments, neither comments. If I switch off the topicintraction plugin, the list of attached files appears. How can I change this behavior that even not-logged people can see the attachments and comments? Naturally to upload stuff or to comment, I would like to have people logged in.

-- ValentinKozlov - 24 Oct 2013

Please remove rest from the {AuthScripts} list. Use restauth for those REST handlers that don't check access rights otherwise.

-- MichaelDaum - 24 Oct 2013

Hi, Would you mind expanding on the second sentence you outlined (use restauth for those REST handlers that don't check access rights otherwise)? I'd guess that the REST handlers that don't check access rights would be in the template maybe? But that seems somehow wrong.

-- RobLeach - 11 Dec 2013

Basically every REST handler must check access on the objects it deals with. Otherwise it is a security issue that even using restauth won't mitigate. A restauth is there to allow the webserver to trigger authentication before it reaches Foswiki internals. It then forces the REST handler to be called with a known user identity. If that's not required, well, then authenticating a rest script isn't either.

Imho, Foswiki listing the normal rest script in {AuthScripts} is therefore a configuration error and it should not be listed there by default as shipped in the foswiki-org-release.

-- MichaelDaum - 12 Dec 2013

Okay thanks for your explanation. So I think the gist of what you're saying is removing the rest script from the {AuthScripts} list solves the problem outlined in the original question.

But it sounds like your first paragraph is outlining a larger issue whereby despite the rest script not being in the {AuthScripts} list it should still check access. If that is correct, then wouldn't that manifest the same issue the original question is asking to solve...?

I guess my point would come back to the question as outlined initially. So regardless of the internals (the rest script details), it should be possible for something more appropriate to be rendered for the attachment tab even if the visitor has not authenticated (logged in). So a guest could see the attachments, and possibly interact with them in a read-only manner without needing to authenticate first.

Am I thinking about this the right way...?

-- RobLeach - 12 Dec 2013

N-N-Not quite sure what you are aiming at.

Basically removing rest from the {AuthScripts} fixes it.

We had an argument on the community long time ago to make this setting of {AuthScripts} the default. Can't remember what the arguments were to leave it in. Imho, that's wrong; only restauth should be in there .... an unresolved task item.

The rest should be available whether you are authenticated already or not, that is not force you thru an authentication loop. If the client is asking for restricted information, then it should simply deny access using the appropriate HTTP error code an explanatory message.

Note that the web-server performing the authentication on that level can only check the identity, but not the clearance on the requested data. In other words, the rest API should only perform necessary steps to check authorization but not authentication. It should simply take the ID as provided in the rest call and proceed.

-- MichaelDaum - 16 Dec 2013

Okay great, that detail helps me understand better.

-- RobLeach - 19 Dec 2013

QuestionForm edit

Subject Using an extension
Extension TopicInteractionPlugin
Version Foswiki 1.1.8
Status Answered
Related Topics
Topic revision: r7 - 19 Dec 2013, RobLeach - This page was cached on 22 Mar 2018 - 05:27.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License