It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

could #103230 be the issue for Windows framework_tests_misc to fail?

this would be awesome if we get this merged!

I pinged the discord chat about looking at this PR

I pinged the discord chat about looking at this PR

Following up from a discussion thread on the discord, it sounds like this isn't actually needed for most developer use cases. @ditman & @yjbanov shall we close this as won't fix?

It would be extremely helpful to get this. I'm currently working on an app using SSO provider that require TLS to be present currently I need to proxy the requests to do the same or run flutter build web and use a webserver with https to serve these files.

I'm sorry, but I am going to be closing this PR as something we are not able to support at this time.

@christopherfujino why are you unable to support at this time?

I pinged the discord chat about looking at this PR

Following up from a discussion thread on the discord, it sounds like this isn't actually needed for most developer use cases. @ditman & @yjbanov shall we close this as won't fix?

@christopherfujino, @ditman, @yjbanov I'm not sure if this is true here.

This is a web only feature since you only need it for flutter web development, mobile or desktop does not need this. So when asking flutter developers if this is a needed feature, all that use flutter only for mobile or desktop development will say no.

For web development it is nessesary since TLS is a requirement for many 3rd party integrations. So the question should go to flutter web developers and according to this issue and #60704 there is enough evidence that this feature is needed.

As already stated in the mentioned issue, without this feature you have to use flutter in a crippled way when developing since you lose the hot reload as well as device specific debug features that come with flutter run which is not usable without providing a way to make TLS work once you hit the TLS barrier of a 3rd party integration. Most commonly SSO providers! Which is a very common use case for web applications.

Currently flutter is not widely adapted to be used for web applications yet, and in my opinion having no support for TLS with flutter run is one big entry barrier here.

TLS is a requirement for many 3rd party integrations.

@c-seeger can you please be more specific about this? "many" sounds to me like a weasel word in this discussion, but concrete use cases would go a long way to sell the value of this feature, and re-prioritize its landing.

All browsers now consider localhost as a secure context¹, so what I'm wondering is:

Is flutter run the right layer at which this fix needs to be applied, or should this be fixed by the 3rd party that requires https in localhost for their service? (And what's the threat model that inspired that requirement on the 3rd party?)

the question should go to flutter web developers

The question did go to our Discord channel #hackers-web (invite link to the server here). I asked for use cases for this, and didn't get an answer.

It is also unclear that this would fix the original issue (Chrome refusing to auto-fill CC fields), see this SO answer (and a fix without certs).

Thanks @ditman for your quick reply.

You are right concret use cases are needed:

I'm currently developing a web/mobile application that uses SSO logins (google, facebook, apple).

The usual workflow here is

• Browser send request to google/facebook/apple
• Browser gets a token back and sends it to our backend
• Our backend validates the SSO token and replies with JWT token (for web in form of http secure only cookie)

Currently if I just use flutter run I only get http://localhost and requesting from http all SSO provider refuse the request due to missing TLS of the requesting origin. I also tried the chrome insecure origins thread as secure which wasn't working for me either, i still get the same result, since the SSO providers enforce the origin to use TLS.

The current workaround I'm using is running a webserver with TLS and using flutter build web instead of using flutter run .

This comes with costs like no hot reload, which slows down implementation speed :(.

The question did go to our Discord channel #hackers-web (invite link to the server here). I asked for use cases for this, and didn't get an answer.

I'm sorry I wasn't aware of this but will join the discord as well (thanks for the link).

It is also unclear that this would fix the original issue (Chrome refusing to auto-fill CC fields), see this SO answer (and a fix without certs).

Thats indeed a good question since I only run into TLS issues using 3rd party integrations, I can not answer this.

Other examples from the #60704

• auto-fill CC (as mentioned unclear)
• authentication (google, apple, facebook, ... my guess is this is also true for all other SSO providers like github, etc)
• grpc backend (no additional context mentioned)
• payment service (indeed!)
• firebase features (not exactly mentioned which ones)

I hope this helps in clarifying the use cases a bit more. Any solution that helps to make flutter run working with the TLS requirement is very appreciated. Thanks again for taking care of this ❤️

an addition:

Is flutter run the right layer at which this fix needs to be applied, or should this be fixed by the 3rd party that requires https in localhost for their service? (And what's the threat model that inspired that requirement on the 3rd party?)

for authentication (as well as payment) it makes sense to enforce the origin to have TLS no matter if it's just a test environment or not. The attack vector here would be the possibility of a network intruder to be able to read sensible data via MITM by modifying the calling page.

https://stackoverflow.com/questions/7594193/calling-https-from-http-through-ajax-for-login

Any plans to get this merged?
As clearly stated by multiple examples in #60704, it is a very much needed feature for proper adoption of flutter as tool for building web apps (in addition to mobile and desktop).

It is a pain to work with APIs like WebUSB/WebSerial/WebNFC or Credential Management API which require HTTPS.
My current workaround is to use package:flutter_cors to turn off all security while testing, but that does not help with WebNFC, since it only exists on Android, where I can't turn security off.

(I've been convinced that we should land this (or a similar version). It'll happen, especially if anybody other than myself refreshes this PR and brings it to mergeability :) )

@ditman Merged and pushed. You can reopen this if required?

@arpitgandhi9 this is failing CLA with the user @arpitignite (are both accounts yours?)

Yes. that's my other account. Let me fix this

@ditman Changes done. Please check

I spent a while banging my head against a wall trying to get nginx to forward to flutter, before I discovered this PR has already fixed this. Could some admin (@ditman @christopherfujino ??) please go add a comment to the bottom of #60704 to let people know this PR has been merged and this is fixed in master? Many thanks!

Good call @jwalton, I just added a comment at the end of the locked issue. Thanks for flagging this!