skeltern

Hi poljpocket, thanks for your helpful and quick answer. It seems that the sessionFingerprint config is the "magic button" here. With fingerprinting false it's possible to login and do things in admin area. Even with HTTPS. That's a huge step forward. The PW config "HTTP hosts whitelist" includes just the main domain plus one dev subdomain. This config is fine. Okay, I think I've to test out the fingerprinting config details now. And to check out CloudFront differences. Can't still see user sessions in EC2 asssets. I think user sessions are stored in CloudFront. However, I hope my main issue is solved.

I've a client with a fresh setup ProcessWire@EC2 plus CloudFront CDN on top. ProcessWire@EC2 is installed and PW admin login works by "hard" IP access over HTTP only (access to EC2 without CloudFront). But I can't login into PW admin panel over the "default" admin path (over CloudFront). With or without HTTPS. I'm the webdev but not the sysadmin. The sysadmin means: "It seems that you've to configure something specific in ProcessWire to allow requests through the CloudFront CDN (with SSL/TLS offloading). ... The fact that CloudFront terminates SSL/TLS could also confuse ProcessWire. Keep in mind that the connection between "client" and "CloudFront" is SSL/TLS encrypted. The connection between CloudFront and ProcessWire is HTTP." I tried some PW configs but with no luck so far (PW config HTTPS full off, DB sessions on, CHMODs). BTW I've never ever seen a stored session file at EC2 in site/assets/sessions. I guess we're not the first people on earth with this setup. Unfortunately I can't find the "magic button" or config to solve the barrier between CloudFront <> EC2. That might by anyone CloudFront settings and/or PW configs. Or some special .htaccess rules? Google did not help me. I would be happy about any hint. ?

Same here. I found out that fieldtype decimal is not ready for different locale settings. English with '.' separator works perfect. But. If you have for example installed the German lang pack or default lang is German the separator is now ',' and not a dot. Defined by correct locale 'de_DE.UTF-8' in language > translate > LanguageSupport.module. As German backend user already filled decimal fields are just showed and saved as blank. Plus you can't add correct data as German editor. It gets always cutted to integer without all digits. I was so pleased about this decimal feature. Unfortunately state today it's only safe usable by single language sites with '.' as language decimal seperator. Only one language with different decimal seperator could result in serious trouble and lost of field values by editing pages... I think this module multilang problem is fixable. Fieldtype float works in same language contexts correct. Maybe with a bug report.

WebP image support is great and works fine. But once created I've issues to get rid of all API generated WebP variations. The backend image field variations "Delete" works and I can remove all variations JPEG plus WebP. Image list is clean but all WebP API variations are still stored in file system (for instance files/12345/84.900x675.webp etc). I can only use ImageSizer with temp 'force' option to request fresh WebP variations or have to delete WebP files from folders. No other way so far. Tested with 2 sites and latest master PW 3.0.165. Is there somewhere a "magic button" or config/setup thing to solve my sticky WebP issue?

The $session feature is easy to use and great to store inputs like currency or cart items temporary on server side. Identified by client cookie ID. I thought the session lifetime works persistent. But the wire cookie is only valid until the browser will be closed. Next visit starts always with a fresh session. All vars got lost. Session file is still on server, but access impossible without cookie ID. Is there anyone way to change the client session cookie lifetime from "expired if browser closed" to maybe "current time plus 48h"? I could create a second beside the "wire" cookie to store things at client side. But all data will saved in client browser directly. The concept to identify via cookie but data always on server is better and more secure. And one cookie is better as two. Which alternative way would you prefer to store some vars for "guest" role users more persistent?

OK, I found a solution for my topic. I copy just all $session values to a bypass array, clean up this array from user related data "_user" and push my stored values back to the new session. I think only the $session key "_user" contains sensible data? In sum, user is after logout "guest" again, but my $session vars got not lost... # COPY SESSION VARS $session_bypass = $session->getAll(); # LOGOUT USER / RESET SESSION if ($user->isLoggedin()) { $session->logout(); } # REMOVE USER DATA FROM SESSION COPY > DELETE KEY "_user" if (array_key_exists ("_user", $session_bypass)) { unset ($session_bypass["_user"]); } # RESTORE SESSION WITHOUT "_user" KEY foreach ($session_bypass as $key => $value) { $session->set($key, $value); }

I use the ProcessWire $session API for a new project to store some things there. Cart items, currency and more. It works fine and the limited lifetime of $sessions is OK, I defined just 3 days. There is only an issue with user $session->logout() to logout an user. It removes all items in user $session too. Website users are just "guest" or after login with role "customer". I see two options to solve my issue: I skip $session API and use instead PHP $_SESSION to keep all vars after $session->logout(). This make things more complicated and I would prefer to use PW API only. Anyone way to avoid the $session->logout() command. So that logout means remove the role "customer" temporary from user session, be only guest. Without $session->logout(). Mhhmmmm. Maybe I think wrong, ideas are welcome. BTW, I enjoy it to work with PW.