cwsoft

Hello all, is there a way to prevent the creation of the Processwire frontend Cookie wire until the user has confirmed/opt-in to allow technical required Cookies? Not too sure, if the wire Cookie is technical really required for PW to do it‘s job (show frontend stuff, remember layout etc.). In Germany it‘s still a bit fuzzy, what technical required means to a lawyer. So ideally there shouldn‘t be set any Cookie without opt-in by the frontend user, unless it is really technical required. Can anybody shine some light on this aspect? For what is the wire Cookie used in the frontend layer, or in other words technical required by the PW frontend? What parts - except admin/backend - of PW wouldn‘t work without that cookie? Looking forward for some hints on that topic.

Just to let you know. Todays demo was a full success. Online booking project will enter next testing stage. However it‘s not yet decided if the project will be realized with PHP/MySQL and Processwire, or Python/Django as the companies internal CMF/CMS of choice used for about 80% of all internal projects.

For WordPress sites I used the Plugin Better Search Replace to replace hardcoded Urls when transferring Sql dumps from localhost to my live server and vice versa. For other CMS I just opened the Sql dump in Notepad++ and did a search/replace of Urls to match right host.

@BoostGuess you talk about converting WordPress site to PW site - right? Would just develop as usual using localhost for the new PW site and then just upload stuff to the server once ready. Usually I have three site/config.php files (config.php, config_server.php, config_local.php) which just differ in the DB credentials and the root host. Once my localhost PW site is up and running, I zip it (.htaccess, index.php, site/ and wire/) and upload the zip file to my server via Ftp together with a simple PHP unzip script. Then I run the unzip script on the server. Than I cooy/rename site/config_server.php to config.php). Last step is to enter my server PhpMyAdmin and just delete old DB tables and import the sql dump from localhost.

Cool. Will test this option too, once I showed the demo to my client and it was decided if and how to proceed with the project. You guys are all awesome and gave me a lot of tips, hints, links and code snippets to check out. @AndyThanks for your sanitizer snippets, already using those on all input data by default. Even do whitelisting whenever appropriate in addition.

@netcarverThanks, already implemented a simple SESSION based math spam protection myself and some honeypot fields. However my client is very paranoid about DSGVO etc. He even worried about the guest Cookie (wire) set by PW by default on startup, even I tried to explain it‘s a technical required cookie set by the underlying CMS, which gets deleted automatically when the browser is closed.

@flydevThanks for your suggestions and links to posts and code examples. Highly appreciated. Got the idea and philosophy already partially by Bernhards YT video, which brought me to PW first place. Was about to start with pure PHP/MySQL, HTML/CSS/JS. Pretty sure I wouldn‘t be that far, as I did my last serious PHP/MySQL project about 5 years ago. So far I am pretty happy with PW and I know I just revealed the absolut basics yet. Looking forward what more to come in the future.

@flydevThanks for this suggestion. Already thought about this too. Guess this would indeed be the best approach. However I came up with another option, as the entire PW booking site should also not show up in Google at all. I simply hid the entire PW side behind a .htaccess AuthBasic login. I may update my PW PHP script creating the booking pages to add .htusers credentials as well or just use a global AuthBasic login for all of the 100-150 users and a unique BookingID per user. So far I am good to go for a limited internal test, just two days ahead of the deadline for the concept study ?. However I will play around with PW frontend login and the FrontendForm module until the project goes live, as I think that‘s indeed the way I should go, as PW already adds security measures for free. Thanks for all your suggestions so far. Highly appreciated.

Hi, just added a fifth option to keep Google and unwanted users out. I Just hid my entire PW booking side behind a .htaccess AuthBasic access. But will try the FrontendForm module too as it seems to already provide all the features I want to implement myself already out of the box ?.

@horstThanks for the tutorial. Still useful for newbies like me. Now I have a German backend too, great!

@AndZyk: Thanks for your input. Will try first with the free FrontendForms module as I am quite new to PW and do not have a lot to deal with web dev recently (more C#, Python stuff for Windows Desktop). Hence I don‘t want yet to spend the 179€ for the pro module unless I will know for sure using PW more often in the future. cheers zx80

@bernhardThanks for your reply. Video was this one Process looks like this. About 100 people get an E-Mail with Url to the PW booking page and a personalized random BookingID (40 random chars) which is not guessable. This part is out of my control and lets say historical grown. The people can check for about 10 events in 2024 and subscribe to one event using their personalized bookingID. Due to data protection concerns, I am not allowed to store any personal data like E-Mail, Name etc. online. Not in PW, nor in textfiles on the server. Thats the constraints I have to fulfill. Hence I wrote a script, which creates 100 booking pages (one per person) which holds the unique bookingID and stores the subscribed eventID and last access time when the form is submitted. Every week a CSV file is created by PW which gets imported into a master Excel spreadsheet (historical grown) to check who subscribed for what event. Thats why I can‘t hide the booking form behind a PW login form per user and hence want to make the form more robust against spam bots and script kids attacks. If I would be free, I would create a different solution, with 100 login pages in the PW backend and without all the hassle of freakling around with Excel sheets at all. But I was really impressed how far I got over the weekend with my first PW installation setup on Friday afternoon last week. But I agree. It‘s important to understand the concept of PW of everything being a page with fields assigned via templates. Thats different from many other CMS I used in the past, but once you got the idea, it starts to make sense quite fast. Cheers zx80

Hello, quite new to PW. I have a project, which uses a frontend form build with basic fields (InputFieldForm) and no user registration or frontend login. What are the best or proposed strategies to secure the form from spam bots and malicious script kids using PW basic fields? Actual form has just build in CSRF protection, but no other stuff like honeypot fields or tracking of failed submits via Session tracking of IP etc. Form will be used by about 100-150 people, but once the stuff goes live, anybody knowing the Url can try to break things. My consideration so far. 1. Add honeypot fields (spam bots) and Captcha to make script attacks less likely 2. Track failed/double submits and ban IP for some increasing time 3. Switch to the free FrontendForms module by Jürgen listed in the PW repo 4. Hide the form behind a PW login page (means to add 1-100 Dummy users with same/individual credentials) What would you propose? Are there links or code snippets showing how to implement those stuff? Any thoughts, hints, tipps or links to resources highly appreciated. Cheers zx80

Hi, damn, data loss sucks. What PW version are you using? Do you have debug on/off? Had some similar issue yesterday but PW showed a warning that some fields/data will get lost and asked if I would like to proceed. Using the latest public release from last week, not the dev version. Have you noticed any warnings before? Cheers

Hi Bill, thanks for your suggestions, pretty much went your proposed way already. I wrote a PHP/PW console script, deleting and adding a page for each possible end user based on a given data template with BookingId, EventId and Last access time. Those fields gets updated based on the chosen form action. Rest was realized with default PW stuff like fields, templates and pages. The selector API you mentioned really makes it easy to find pages/fields, get/set/update field data on the fly and to sanitize user input. Quite impressing how far I got in two days from scratch with my very first PW project and some medium PHP level skills. Finished a working prototype this morning. Now need to add some security features to the form like IP reload/retry ban and Captcha. Will check out the API documentation and see how to implement those stuff.

Hi there, as I did not yet understand the repeater field options, I just created a booking container page holding the booking details in three fields on various child pages (one child page per MySql row). This approach seems to work. Are there any more advanced techniques I can use to accomplish the same task? Cheers

Good evening to all, watched a youtube video about Processwire a few days back from Bernhard Baumrock and thought I deep dive into this CMS/CMF and try to realize a new project with it. My project basically deals with the subscription to some events (10-20). Basic idea is that potential guests get an E-Mail with the Url and a random unique personalized GUID (40 chars) used to assign to free slots via a public Form without having access to the backend at all. Started with the Intermediate PW install and managed to setup an overview page showing a table with events pulled from it‘s child pages, a detailed page showing all infos for the actual event. Also managed to setup a custom form with three actions (subscribe, unsubscribe and check status of booking). For data storing I would like to create a settings page with text fields for the unique bookingID, a text field for linking a eventID to the bookingID and a datetime field to store the date of the submission. The bookingIDs will be available from start, where eventID and datetime are NULL first and get’s updated depending on the form action taken. I will have to store a table with about 100 entries (Sql rows) and 3 fields (Sql columns). Can this be realized with a repeater and the three custom fields? Should this page be a admin page, or a hidden frontend page? Are there any other options to store this values and access it via the PW API? Any hints would be highly appreciated. Cheers zx80