smd_access_keys: secure, limited access to content

giz · 2023-03-09 18:54:19

Thank you; the new keys button is working.

Yesterday I experimented with creating the key from a tag, and everything behaved as expected, apart from the ‘Access Attempts’ count which remained at 0.

I’m afraid the updated plugin still shows 0 access attempts, and doesn’t protect the content i.e. content wrapped in <txp:smd_access_protect /> displays whether I append the key to the url or not.

<txp:smd_access_protect trigger="test">
   <p>Protected content</p>
</txp:smd_access_protect>

Both https://domain/blah and https://domain/blah?test/b0dc6cd2f5c258c7c643fa61f36c08edf1e9f07d/640a25b1.3 display the snippet <p>Protected content</p>.

Here’s hoping its a misunderstanding on my side on how to use the plugin!

Last edited by giz (2023-03-09 19:10:36)

Bloke · 2023-03-09 19:09:34

Have you tried adding force="1" to the protect tag? Although that does put it in brute force mode and will reject pretty much anything without a token, so if you’re only protecting a small portion of the page, it might be a bit overkill.

I’ll have to do some experiments and check I’ve not introduced something stupid.

Edit: is there any reason you’re using the ? messy syntax instead of a forward slash, btw?

Last edited by Bloke (2023-03-09 19:11:33)

giz · 2023-03-09 19:20:12

Hey

I did in earlier tests, but forgot to add it to my sample snippet above.

<txp:smd_access_protect trigger="test" force="1">
   <p>Protected content</p>
<txp:else />
   <txp:smd_if_access_error type="smd_akey_err_forbidden">
      <p>Before you can view this item, you'll need an access key.</p>
   </txp:smd_if_access_error>
</txp:smd_access_protect>

Interesting: this displays <p>Before you can view this item, you'll need an access key.</p> with both urls.

Last edited by giz (2023-03-09 19:31:40)

Bloke · 2023-03-09 19:26:38

Right, it pretty much stomps on every request. It’s designed primarily for situations where you want to protect the whole page.

Hmmm. I’ll run some tests and see if I can make it behave more sanely. And I’ll check out the counter. It was incrementing for me earlier but I only tested it when protecting an article.

giz · 2023-03-09 19:32:00

This may help: <txp:smd_access_info item="trigger" /> does not display anything when using the key in the url.

Bloke · 2023-03-09 23:24:55

Okay, this is where I kinda wish I’d made a mental note to myself about why I coded something the way I did, goodness knows how many years ago. Or at least an example or something that explains my thinking.

I can’t figure why anyone would want the force attribute to ever be zero. i.e. to show the content inside the protected tag regardless of whether the trigger/token is supplied. There must have been a use case for it, as it’s the default behaviour. But it just seems… bizarre.

I’m considering rewiring that attribute, or ditching it and renaming it to something else, to maintain backwards compatibility. Maybe some type attribute. But I can’t think of any reason to even have the attribute at all.

It’s clearly designed in this manner because if the trigger is missing, the code does this:

// If we always want to forbid access to this page regardless if the trigger exists.
if ($force) {
    $smd_access_error = 'smd_akey_err_forbidden';
    $smd_access_errcode = 401;
} else {
    $ret = true;
}

In other words, I did it on purpose. And if you leave force out or set it to zero, the content will always be displayed (true).

What was I thinking? Anybody any ideas, haha?

EDIT: This post sheds a little light on why it might be necessary to retain the concept of non-forced access keys. Basically if you’re looping over something and only want to protect a subset of the data. If force was used, all the content would be access protected. But it doesn’t help insofar as supplying no trigger and no key will reveal the content, which seems bizarre.

Last edited by Bloke (2023-03-10 00:25:07)

Bloke · 2023-03-10 00:59:54

This commit introduces force="partial" which allows you to use one or more smd_access_protect tags to surround content blocks and will not reveal the contents, but will also not throw an error (like force="1" does) if the trigger is not provided.

If this is broadly useful I’ll adopt it from this point forward.

Bloke · 2023-03-10 01:07:27

giz wrote #334991:

<txp:smd_access_info item="trigger" /> does not display anything when using the key in the url.

You are putting that tag inside <txp:smd_access_protect>, right? It won’t work outside of the protection context.

the updated plugin still shows 0 access attempts

That should count properly if the trigger is supplied. Without that, the counter remains at its last value. Try it with the new force="partial" and see how you get on. And remember that you can match multiple triggers as a comma-separated list, and use a different trigger_mode to perform subsets of matches.

giz · 2023-03-10 19:23:53

Thanks Stef.

Bloke wrote #334995:

You are putting that tag inside <txp:smd_access_protect>, right? It won’t work outside of the protection context.

That should count properly if the trigger is supplied. Without that, the counter remains at its last value. Try it with the new force="partial" and see how you get on. And remember that you can match multiple triggers as a comma-separated list, and use a different trigger_mode to perform subsets of matches.

Yes; I tried inside and out ;-)

I applied your ‘partial’ commit:

<txp:smd_access_protect trigger="test" force="partial">
	<txp:smd_access_info  item="trigger" />
	<p>Protected content</p>
<txp:else />
  <txp:smd_if_access_error type="smd_akey_err_forbidden">
    <p>Before you can view this item, you'll need an access key.</p>
  <txp:else />
    <txp:smd_access_error item="code, message" break="br" />
  </txp:smd_if_access_error>
</txp:smd_access_protect>

and get these results whether the key is included in the url or not:

force=“partial”: Before you can view this item, you’ll need an access key.
force=“1”: Before you can view this item, you’ll need an access key.
force=“0”: Protected content.

Manage Keys tab shows 0 Access Attempts, and <txp:smd_access_info item="trigger" /> is silent.

Can you see anything wrong with my approach?:

clone your latest commit to textpattern/plugins/smd_access_keys/smd_access_keys.php
update from disk in the admin:plugins tab
delete old test keys
create a new key: https://domain.com/etc/professional-access test 2023-03-11 06:11:48 - 0 0
1. Access key: https://domain.com/etc/professional-access/test/4ad96534b927bf16324176bca5a8b9ea964865b9/640b80f4
2. Convert to section_mode=“1” Access key: https://domain.com/etc/professional-access?test/4ad96534b927bf16324176bca5a8b9ea964865b9/640b80f4
visit the page where my <txp:smd_access_protect /> snippet resides

Bloke · 2023-03-10 19:29:41

Hmm, looks reasonable. Stick your site in debugging mode and refresh the page, with and without the key(s) / section mode in the URL. Then view source on each. If you hunt in the stack trace for the smd_akey / smd_access_key entries you should see a chunk where the smd_access_protect is called.

Straight after that will be what it pulled form the URL and the corresponding DB query. Then the result of the trigger test. Check that the URL and trigger exactly match, and compare them to the corresponding entry in the database smd_akey table (match on the t_hex). Then see what the result is in the stack trace. It should report true or false. This might give us a clue why it’s failing.

In general, you only need section mode if you’re protecting an entire section of your site. If you’re protecting an article you should be able to get away without it.

EDIT: also, what’s the URL scheme of the section that you’re protecting?

Last edited by Bloke (2023-03-10 19:34:06)

giz · 2023-03-10 19:49:37

Thanks.

Plain url:

    135.13 |     1.96 | 	<txp:smd_access_protect trigger="test" force="partial">
    135.19 |     1.84 | 		[SQL: SHOW columns FROM smd_akeys ]
    137.03 |          | 		[Rows: 8]
    137.05 |          | 		[smd_access_key URL elements: https:||domain.com|etc|professional-access]
    137.06 |          | 		[smd_access_key trigger: test]
    137.07 |          | 		[false]
    137.07 |     0.02 | 		<txp:smd_if_access_error type="smd_akey_err_forbidden">
    137.08 |          | 			[true]
    137.09 |          | 		</txp:smd_if_access_error>
    137.09 |          | 	</txp:smd_access_protect>

Url with key:

    136.79 |     1.48 | 	<txp:smd_access_protect trigger="test" force="partial">
    136.84 |     1.30 | 		[SQL: SHOW columns FROM smd_akeys ]
    138.14 |          | 		[Rows: 8]
    138.19 |          | 		[smd_access_key URL elements: https:||domain.com|etc|professional-access?test|3492257933d99276d24517fece7b28a31d777958|640b881e]
    138.20 |          | 		[smd_access_key trigger: test]
    138.22 |          | 		[false]
    138.23 |     0.04 | 		<txp:smd_if_access_error type="smd_akey_err_forbidden">
    138.26 |          | 			[true]
    138.27 |          | 		</txp:smd_if_access_error>
    138.27 |          | 	</txp:smd_access_protect>

Both key and trigger match. The url scheme is section/title

Last edited by giz (2023-03-10 19:53:42)

Bloke · 2023-03-10 20:01:16

So the plain URL is behaving as expected. The one with the ? In the URL isn’t, and that might be because it’s not acting as a section mode key.

When you say “convert to section mode” did you edit the smd_access_protect tag to add section_mode="1"? Without that, it’ll still be trying to match on slash.

giz · 2023-03-10 20:28:06

That did it :)

I remember trying section_mode=“1” in the smd_access_protect tag earlier, but obviously something else I’d done was preventing it from working then.

Thanks for all your help!

Bloke · 2023-03-10 20:32:48

No worries, got there in the end. Sorry for the hassles.

Textpattern CMS

Textpattern CMS support forum

#136 2023-03-09 18:54:19

Re: smd_access_keys: secure, limited access to content

#137 2023-03-09 19:09:34

Re: smd_access_keys: secure, limited access to content

#138 2023-03-09 19:20:12

Re: smd_access_keys: secure, limited access to content

#139 2023-03-09 19:26:38

Re: smd_access_keys: secure, limited access to content

#140 2023-03-09 19:32:00

Re: smd_access_keys: secure, limited access to content

#141 2023-03-09 23:24:55

Re: smd_access_keys: secure, limited access to content

#142 2023-03-10 00:59:54

Re: smd_access_keys: secure, limited access to content

#143 2023-03-10 01:07:27

Re: smd_access_keys: secure, limited access to content

giz wrote #334991:

#144 2023-03-10 19:23:53

Re: smd_access_keys: secure, limited access to content

Bloke wrote #334995:

#145 2023-03-10 19:29:41

Re: smd_access_keys: secure, limited access to content

#146 2023-03-10 19:49:37

Re: smd_access_keys: secure, limited access to content

#147 2023-03-10 20:01:16

Re: smd_access_keys: secure, limited access to content

#148 2023-03-10 20:28:06

Re: smd_access_keys: secure, limited access to content

#149 2023-03-10 20:32:48

Re: smd_access_keys: secure, limited access to content

Board footer