In case someone missed it, maybe worth to take a look:
PS: I have only reCAPTCHA, if I remove it, there is no warning, so, there’s something we should worry about?
What about cookies between backend and localhost, in a mobile app? It’s there too.
3 Likes
Thanks for raising this. I’ve noticed the messages as well. I’m interested in best practice solutions/ alternatives for Wappler sites.
@George any thoughts?
Bump
Even outside Wappler it seems it’s not very clear what solutions are being taken.
Maybe the “solution” will be to replace for another captcha that doesn’t need cookies…
But I also see some docs about “partitioned cookies”, no idea what it means but sounds like a possible workaround once someone figures what that means and how to use… 
There are already lot of recent topics about Google reCaptcha and we probably need a new plugin that is safe to use within the Europe according to the GDPR rules and without usage of 3rd party cookies (which would also require cookie consent in Europe).
I normally don’t like the use of captcha but often apply a honeypot, the same is used against xhr attacks. You simply place a hidden input in the form and set the value from it on the server with some unique identifier, store that unique identifier in a session and verify it when the form is being posted.
2 Likes
@patrick in fact, I’m actually thinking about security provider and cross domains.
In a capacitor app we are not allowed to use domain.com -> localhost anymore?
Or there’s something you/we need to do in order to be safe with that?
The warning appears on a succesfuly android login with mydomain -> localhost and I understand that’s the way to do it according the capacitor docs and the advice of the ionic team.
We currently rely on the session cookie for the user authentication. If instead we use some token that we send to client after login and then use that token with each request to authenticate the user we don’t have the cookie problem anymore. The token could simply be the session id or a json web token. On the client you could store it in local/session storage or a local database (sqlite).
Thanks @patrick, for confirming this.
I know there’s alternatives, but can we use rws as a method?
Will security provider work with this?:
{
"primary": "https://domain.com",
"associatedSites": "http://localhost"
}
Or we should consider no more cookies for this case?
I’m asking this because it’s on the link up there but I don’t know if there’s a workaround, or we should start thinking on token.
Again thanks.
Meanwhile in a meeting with Human Resources at Google…
1 Like
The next time I want to create a tutorial, I’ll ask on google: how long will this work?
Spended more than a month with @milo to get third party cookies working on android/ios 
I don’t think Related Website Sets are going to help since all sites should be https for it and localhost isn’t.
This sounds like an interesting solution. Would this work in oauth scenarios as well (like if a user authenticates to the wappler site via Google, FB, etc.)? Also is there a time line for an update? Per this article Chrome is already blocking 3rd party cookies for 1% of users with a full roll out planned “from q3 2024” which could be from end of June https://developers.google.com/privacy-sandbox/blog/cookie-countdown-2023oct
OAuth is already using a token based authentication.
For websites it is still common to store the credentials in a session and have a session cookie. This will still be possible since in most cases it is not a 3rd party cookie and since it is an essential cookie consent is also not needed. The advantage of sessions is that you have the authentication available in each request and you can restrict pages on the server when authentication is missing.
With API request from the client you can add extra headers to add an authentication token, but with the normal browser request you can’t while the session cookie is always being send.
The problem is for mobile app development where the app is mostly not running on the server but on the device and the server is seen as a 3rd party provider. Most mobile apps work with token based authentication, this means you must first request a token (can be an api key, oauth token, json web token etc.) and use that token in every request you make to the server.
So for websites the current Security Provider works fine and it will keep working even when 3rd party cookies are blocked. We need a new solution for when the server is being used as an API by a mobile app or a 3rd party domain.
We haven’t planned anything yet, so suggestions are welcome.
Wenn using a token we need to store it somewhere and bind it to a user, this would probably be in the database where also the users are stored. Alternative we could have the encrypted user credentials on the client (this is how the remember me cookie works) and send this with each API request, it does then a login with this credentials on each request. We could also provide all the methods and let you the developer choose which method to use, we then just create extra actions for token generation and encrypted user credentials.
5 Likes
How about using Passport JS? There are enough requests for it, and would it not resolve this issue? We just had a similar issue and are not happy with our 'temporary' solution whereby we work off the Unauthorized response. We would much rather prefer a correct and secure method other than a work-around...
So in the end they won't be blocking third party cookies 
1 Like