Recently Browsing 0 members
No registered users viewing this page.
I would like to set an admin template to 'https only' as recommended in the Processwire security docs.
However if I do this it forces this setting locally too, resulting in https://localhost requests which result in an error page.
Is there a simple way round this? Setting https for templates in the config?
addHookBefore('Session::redirect', ...) not working if template-settings-based PW redirects are usedBy theoretic
Hi guys and ladies! And thanks for Processwire!
It appears i've got an interesting issue concerning the template-settings-based PW redirects dealing with access control. Any PW template has some access control options i.e. "Login redirect URL or page ID to render". If this option is used for a page having a template with this option filled, a redirect will occur if user is not logged in and/or has insufficient access rights.
I like to hook PW events. In one of my current projects i decided to write an addHookBefore('Session::redirect', ...) which should store the page we are being redirected from. With "regular" redirects like $session->redirect('/somewhere/') this hook works like a charm. But it was strange to see that it doesn't work with the template-settings-based redirect.
I'm too dumb to dive deep inside PW and to examine the whole PW session mechanism. But it could be rather logical if ANY redirect ( no matter template-settings-based or using $session->redirect() ) could be hooked in the same manner.
Okay okay i can forget about template-settings-based redirect and write my own. Just a couple of lines of code, and it works. But it's less elegant than hooking the template-settings-based redirects.
So am i missing something? It this behavior a bug, or is it intended by PW team? Thanks in advance for any comment!
By Guy Incognito
What's the best process for adding another user with TfaTotp 2FA? Just using it for the first time.
Should I supply them with them with the secret when I first create their account? Seems like a security risk?
Otherwise how do I create a 2FA user and let them login for the first time?
By Chris Bennett
Plenty of posts on the forum relating to Content Security Policy (CSP) and how to integrate it with Processwire.
It's not too hard to implement a decent htaccess CSP that will get you a solid B+ at Mozilla Observatory.
If you're after A+ it's a little harder because of all the back-end stuff... until you realize it's surprisingly easy.
After a lot of testing, the easiest way I found was to specify only what is needed in the htaccess and then add your required CSP as a meta in your page template.
Plenty of people have suggested similar. Works very easily for back-end vs front-end, but gets complicated if you want front page editing.
Luckily, a little php will preserve back-end and front page editing capabilities while allowing you to lock down the site for anyone not logged in.
None of this is rocket science, but CSPs are a bit of a pain the rear, so the easier the better, I reckon 😉
The only CSP I'd suggest you include in your site htaccess is:
Header set Content-Security-Policy "frame-ancestors 'self'" The reason for this is you can't set "frame-ancestors" via meta tags.
In addition, you can only make your CSP more restrictive using meta tags, not less, so leaving the back-end free is a solid plan to avoid frustration.
Then in your public front-facing page template/s, add your desired Content Security Policy as a meta tag.
Please note: your CSP should be the first meta tag after your <head>.
<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Security-Policy" content="Your CSP goes here"> <!-- followed by whatever your normal meta tags are --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="format-detection" content="telephone=no"> If you haven't got Front Page Editing enabled, this works fine by itself.
Just one extra step is needed to make sure you don't have to worry either way.
The easiest way I found to allow both CSP and front page editing capabilities is the addition of a little php, according to whatever your needs are.
Basically, if the user is a guest, throw in your CSP, if they're not do nothing.
It's so simple I could have kicked myself when it finally dawned on me.
I wish it had clicked for me earlier in my testing, but it didn't so I'm here to try to save some other person a little time.
<!DOCTYPE html> <html> <head> <?php if ($user->isGuest()): ?> <meta http-equiv="Content-Security-Policy" content="Your CSP goes here"> <?php endif; ?> <!-- followed by whatever your normal meta tags are --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="format-detection" content="telephone=no">
If you want it a bit more involved then you can add additional tests and be as specific as you like about what pages should get which CSP.
For example, the following is what I use to expand the scope of the CSP only for my "map" page:
<?php $loadMap = $page->name === "map"; ?> <!DOCTYPE html> <html> <head> <?php if ($user->isGuest()): ?> <meta http-equiv="Content-Security-Policy" content="default-src 'none'; base-uri 'self'; manifest-src 'self'; form-action 'self'; font-src 'self' data: https://fonts.gstatic.com; frame-src 'self' https://www.youtube.com; img-src 'self' data:<?php echo ($loadMap) ? " https://maps.googleapis.com https://maps.gstatic.com" : ""; ?> https://www.google-analytics.com; script-src 'self' <?php echo ($loadMap) ? "https://maps.googleapis.com " : ""; ?>https://www.google-analytics.com https://www.googletagmanager.com; style-src 'self' <?php echo ($loadMap) ? "'unsafe-inline' https://fonts.googleapis.com" : ""; ?>"> <?php endif; ?> Hope this saves someone a little time testing.
Hello forum, this is my first security related post, so I'm a bit of a newbie.
I understand that when I have direct front-input from user I should sanitize the input, but how about when I use a secret key for showing a API for a third-party supplier? Should I sanitize the input->get() key?
I've tested this issue and I tried ?key=<?php echo $page->field; ?> And without adding any sanitization it comes back: /?key=<?php%20echo%20$page->field;%20?>
So can I rely on this, or should I still use $sanitizer just in case?
Thanks for the help!