Hi again,
Thank you all for your feedback.
A lot of Cordova users will never enable this feature if it is an
opt-
in feature.
This is a very good reason for me as well.
I created a PR which introduces a preference to make the
WebViewAssetLoader opt-out: https://github.com/apache/cordova-
android/pull/1222. Please leave your review.
Is this a way to proceed for cordova-android 10?
Regards
Niklas
On April 29, 2021, Pieter Van Poyer
<pieter.vanpo...@portofantwerp.com>
wrote:
Hey
I have to agree with Bryan and Julio.
Make it opt-out with a next major release. That's my prefered
option.
A lot of Cordova users will never enable this feature if it is an
opt-
in feature.
And yes it would be great if someone did already have some
guidelines
about data migration.
Kind regards
Pieter Van Poyer
-----Oorspronkelijk bericht-----
Van: Niklas Apache <niklasm...@apache.org>
Verzonden: woensdag 28 april 2021 12:14
Aan: dev@cordova.apache.org
Onderwerp: Re: [DISCUSS] Moving forward with the WebView on AndroidX
and cordova-android 10
I would agree with Bryan and Julio that we should use the
opportunity
of this breaking release to move the defaults to current Android
best
practices and remove deprecated settings.
I just started a PR [1] that introduces a preference to allow the
use
file URLs with this release. This means the deprecated settings
[2][3]
are only set with this settings as well. Darryl is right that
probably
many still need to run their app on the file protocol and they
should
have an easy option to do this with the new release. We can now push
new users to avoid this and current users need to check the change
log
and enable this if they really need to.
I agree we shouldn't take the responsibilty of a data migration.
If we don't find consensus to make the WebViewAssetLoader opt-out we
could make it opt-in for now. This would make the upgrade more safe
but potentially many apps less secure because developers don't need
to
think about this change.
[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-
android%2Fpull%2F1222&data=04%7C01%7CPieter.VanPoyer%40portofantwerp.com%7C3874f4566f504fbf6fca08d90a2e5037%7C2337dcc63a214d95bf72da5551a9b048%7C0%7C0%7C637552016304717784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yaRNsgmiLk6XqWC3NgWiceVCCF4RiEcwDzFuYzVVU%2Fg%3D&reserved=0
[2]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.android.com%2Freference%2Fandroid%2Fwebkit%2FWebSettings%23setAllowUniversalAccessFromFileURLs&data=04%7C01%7CPieter.VanPoyer%40portofantwerp.com%7C3874f4566f504fbf6fca08d90a2e5037%7C2337dcc63a214d95bf72da5551a9b048%7C0%7C0%7C637552016304717784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZbClSYsggi0ckZgdsSOHJ1Tq6zermY2krIB4zWjngcw%3D&reserved=0(boolean)
[3]https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.android.com%2Freference%2Fandroid%2Fwebkit%2FWebSettings%23setAllowFileAccess&data=04%7C01%7CPieter.VanPoyer%40portofantwerp.com%7C3874f4566f504fbf6fca08d90a2e5037%7C2337dcc63a214d95bf72da5551a9b048%7C0%7C0%7C637552016304717784%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=e%2FP3sN894F9SIYkkBSE9Q%2BFz%2FowbKUu4r1le8TgIcf4%3D&reserved=0(boolean)
On April 28, 2021, julio cesar sanchez <jcesarmob...@gmail.com>
wrote:
My understanding is that file urls can technically continue
working,
but the defaults changed and some settings need to be enabled, and
some of them are now deprecated and will stop working at some
point
in
the future.
I think defaulting to the old behavior is ok when doing minor
releases
(not just on, but enforced because otherwise it's a breaking
change),
but whenever we make a major release, we should always use the new
behavior and make the cordova user responsibility to enable the
old
behavior if they need it, because to not "break" existing apps we
will
make all new apps to face the same problem in the future.
About the data loss, the data is not really lost, the data is
still
there, but since the scheme and hostname change it's not accesible
anymore, so if the cordova users can enable the old behavior
they'll
get the data back and should be their responsibility to do so if
needed and do it before releasing a new version. We should of
course
warn about it so they will be aware if they read the release blog
post
or change log.
If cordova does the data migration is when we can screw up and do
it
wrong and cause the massive data loss for all users, I prefer to
not
put that responsibility into the project. You have not tried to do
it
in your own apps because it's risky, would you be confident to do
it
for all users?
2021-04-27 21:15 GMT+02:00, Darryl Pogue <dar...@dpogue.ca>:
To counter a bit, all of my apps are using the standard Cordova
Android WebView, and store all their data in the browser's
indexedDB.
I've had no issues with file URLs (although I expect that will
change
with API 30 enforcement).
Losing data in an app update is unacceptable, and for many apps
it
would be catastrophic (see comments from when Google did a bad
indexedDB migration and people lost data[1]). On iOS with
WKWebView,
I'm stuck in the position of continuing to use file URLs to keep
existing data working because there's no supported path for data
migration to the new scheme.
We made the decision with Cordova iOS to use file URLs by
default
to
ensure that we didn't unexpectedly break existing apps.
We either need to default to using file URLs on Android (which
is
risky considering the API 30 enforcement is restricting what
works
there), or provide an officially supported update path that
preserves
and migrates all the relevant data. (If we opt for the migration
path,
it would be nice to have it support iOS as well.)
If we release a Cordova update that causes a bunch of existing
Android
apps to lose all their data, it will very likely be a public
image
disaster from which we will never recover.
[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu
gs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1033655&
data=04%7C01%7CPieter.VanPoyer%40portofantwerp.com%7C3874f4566f504fb
f6fca08d90a2e5037%7C2337dcc63a214d95bf72da5551a9b048%7C0%7C0%7C63755
2016304727782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5XgUsbuMjAvfG7
l9giIlf2WEuq9VJ8%2FKhN3tOds8rRk%3D&reserved=0
On Tue, Apr 27, 2021 at 8:48 AM Bryan Ellis <er...@apache.org>
wrote:
I also agree.
I think we should move forward with these changes and use the
WebViewAssetLoader by default.
If must, we could write a blog post explaining how to use
Norman's
plugin
for data migration. But I do not know if the plugin is complete
to
cover
all data sources and fits this case.
I believe the change though is necessary.
Starting from API 30, Google has disabled file access to the
WebView
because it introduces possible security risks.
Apps should not open file:// URLs from any external source in
WebView,
don't enable this if your app accepts arbitrary URLs from
external
sources.
In our recent release of Cordova-Android, we explicitly set the
`setAllowFileAccess` to `true` to get around the change that
came
in the
API 30 release. This allowed apps to continue working
temporarily,
while
we would introduce a proper solution in this coming major
release,
preferably following a secure implementation. I believe we
should
not
default to something that has been publicly announced and known
to
lead to
potential security risks.
If we want to support the file scheme to allow users to avoid
data
loss, I
think a config.xml flag can be introduced that users can
manually
set if
they are willing to accept the potential security risks that
exist
with
it. And it could allow them to move over whenever they decide.
On Apr 27, 2021, at 9:07 PM, julio cesar sanchez
<jcesarmob...@gmail.com> wrote:
I would vote for defaulting to WebViewAssetLoader but still
allow
using
file:// from a config.xml preference for the people that are
not
ready
to
move on.
But on cordova-ios 6 I think we ended up defaulting to
file://
and use
the
schemes only as opt-in.
About migrating data, I don't think that's our job, but we
can
point
users
to plugins if you know some.
El mar, 27 abr 2021 a las 8:03, Niklas Apache
(<niklasm...@apache.org>)
escribió:
Hey folks,
we recently merged a PR [1] which significantly changes how
cordova-
android loads web content in the webview and now need to
decide
how to
move proceed.
Google introduced the WebViewAssetLoader to make it possible
to
use
web
content from a standard http(s) scheme instead of file:.
This
was done
to remove security risks [2] and some apps with routing
frameworks
like
React and Angular need this for proper routing.
Because cordova-android 10 now uses AndroidX we could
implement
the
WebViewAssetLoader and remove some deprecated or security
related
WebSettings and move the platform forward to current Android
standards.
This change may break some apps now because the origin
changes
if the
app now runs on https://localhost for example instead of
file://.
Changing the origin means losing access to web storage like
localstorage, indexedb etc. First and foremost we need to
announce
that
change with the release for developers to act but
additionally
we
could
do:
1.) Default back to file:// and make the WebViewAssetLoader
opt-
in via
config.xml. This exposes apps to the security risk:
Note: Apps should not open file:// URLs from any external
source in
WebView, don't enable this if your app accepts arbitrary
URLs
from
external sources. It's recommended to always use
androidx.webkit.WebViewAssetLoader
<
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve
loper.android.com%2Freference%2Fandroidx%2Fwebkit%2FWebViewAssetLoader
&data=04%7C01%7CPieter.VanPoyer%40portofantwerp.com%7C3874f4566f50
4fbf6fca08d90a2e5037%7C2337dcc63a214d95bf72da5551a9b048%7C0%7C0%7C6375
52016304727782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1gKnQsRLBinJl96WQ
DS06aZ3LPIoyle6glQDAvF7BOc%3D&reserved=0
to access files including assets and resources over
http(s)://
schemes, instead of file:// URLs. To prevent possible
security
issues
targeting
Build.VERSION_CODES.Q
<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdev
eloper.android.com%2Freference%2Fandroid%2Fos%2FBuild.VERSION_CODES%23
Q&data=04%7C01%7CPieter.VanPoyer%40portofantwerp.com%7C3874f4566f5
04fbf6fca08d90a2e5037%7C2337dcc63a214d95bf72da5551a9b048%7C0%7C0%7C637
552016304727782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7gg4w3lJS%2FJf3P
eVq2ybdUx2aKG1FvsiTJ%2BSPZnkrlA%3D&reserved=0>
and earlier, you should explicitly set this value to false.
2.) Add a migration for localstorage etc. to the platform to
provide a
smoother transition
3.) Use the WebViewAssetLoader only and don't migrate in the
platform
but point users to a plugin that helps them to manage their
migration
Personally I would favor to move to WebViewAssetLoader by
default in
this breaking release to get apps up to date and adapt to
Androids
changes. I don't know how many apps would be affected
because
I
suspect many apps are using native storage solutions (SQLite
etc.) or
are
running Ionics WebView with the https scheme already. I am
doing
both
for my apps because of the many localstorage and non https
scheme
issues
we had in the past and I suspect many did as well.
Cordova Android 10 needs to be released rather sooner than
later
so
please leave your feedback.
Thank you very much and kind regards Niklas
[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%
2Fgithub.com%2Fapache%2Fcordova-
android%2Fpull%2F1137&data=0
4%7C01%7CPieter.VanPoyer%40portofantwerp.com%7C3874f4566f504fbf6
fca08d90a2e5037%7C2337dcc63a214d95bf72da5551a9b048%7C0%7C0%7C637
552016304727782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jWKS
fmrX8SwsBbBT2L0QgsA58F3%2FmCNiz%2BGr4d7TzZ8%3D&reserved=0
[2]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeve
loper.android.com%2Freference%2Fandroid%2Fwebkit%2FWebSettings%23setAl
lowFileAccess&data=04%7C01%7CPieter.VanPoyer%40portofantwerp.com%7
C3874f4566f504fbf6fca08d90a2e5037%7C2337dcc63a214d95bf72da5551a9b048%7
C0%7C0%7C637552016304727782%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SzzK
WCqJdddbznOsxQxT5p9NiXIxQDT0DaGJMy1mTRY%3D&reserved=0(boolean)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
--
___________________________________
Julio César Sánchez
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
________________________________
Deze e-mail en alle gekoppelde bestanden zijn officiele documenten
van
Havenbedrijf Antwerpen NV van publiek recht en kunnen vertrouwelijke
of persoonlijke informatie bevatten. Gelieve de afzender
onmiddellijk
via e-mail of telefonisch te verwittigen als u deze e-mail per
vergissing heeft ontvangen en verwijder vervolgens de e-mail zonder
deze te lezen, te reproduceren, te verspreiden of te ontsluiten naar
derden. Havenbedrijf Antwerpen NV van publiek recht is op geen
enkele
manier verantwoordelijk voor fouten of onnauwkeurigheden in de
inhoud
van deze e-mail. Havenbedrijf Antwerpen NV van publiek recht kan
niet
aansprakelijk gesteld worden voor directe of indirecte schade,
verlies
of ongemak veroorzaakt als gevolg van een onnauwkeurigheid of fout
in
deze e-mail.
English Translation: This e-mail and all attached files are official
documents of Antwerp Port Authority and may contain confidential or
personal information. If you have received this e-mail in error, you
are asked to inform the sender by e-mail or telephone immediately,
and
to remove it from your system without reading or reproducing it or
passing it on to other parties. Antwerp Port Authority is in no way
responsible for any errors or inaccuracies in the contents of this
e-
mail, nor can it be held liable for any direct or indirect loss,
damage or inconvenience arising from any such errors or
inaccuracies.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
