Hello,
> I'm not a system administrator on a company but a support vendor for
> enterprise customers and I provided different versions for each ESR68
> customer as sideloaded addons. Thus I think I must provide repacked XPIs
> for each customer on the next ESR...
After this reply I've found a possible solution without custom update
info: custom ID (and URL) including version number, like:
{ "policies": {
"Extensions": {
"Install": [
"https://example.com/[email protected]?version=3";
],
"Locked": [
"[email protected]"
],
"Uninstall": [
"[email protected]",
"[email protected]"
]
}
}}
Or:
{ "policies": {
"ExtensionSettings": {
"[email protected]": {
"installation_mode": "force_installed",
"install_url":
"https://example.com/[email protected]?version=3";
},
"[email protected]": {
"installation_mode": "blocked"
},
"[email protected]": {
"installation_mode": "blocked"
}
}
}}
It looks suck but easier than providing custom update info.
(Sorry but the second example is not tested yet by me actually.)
On 2019/11/02 1:25, SHIMODA Hiroshi wrote:
> Hello,
>
>> To clarify, loading them directly into <FF/TB install>/extensions is
>> going away, and the "as normal extensions" deployment means loading into
>> distribution/extensions, where they are copied into and then run from
>> the user profile?
>
> If I understand the blog post correctly, it is "yes".
>
> As the result version lock and controlling of update timing about addons
> installed in this way (or via GPO) become virtually impossible.
> Sideloaded addons can be updated by simple replacing of installed files.
> On the other hand, updating of addons installed into user profiles can
> be done only via the auto update. (It is painful for the system
> administrator that replacing all files placed under each user profile.)
>
> Otherwise, I think we need to distribute addon packages with custom
> update URL for each case. If the addon is a public addon, you look to
> need to repack it with custom ID and custom update URL.
>
> https://extensionworkshop.com/documentation/manage/updating-your-extension/
>
> I'm not a system administrator on a company but a support vendor for
> enterprise customers and I provided different versions for each ESR68
> customer as sideloaded addons. Thus I think I must provide repacked XPIs
> for each customer on the next ESR...
>
>
> On 2019/11/02 1:04, Kris Lou via Enterprise wrote:
>> The thing that is going away is the concept of sideloading where you
>> put extensions in a central location and they get loaded into
>> Firefox and the user can't remove them (they can only disable them).
>> You will still be able to put extensions into
>> distribution/extensions because they simply get installed into
>> Firefox as normal extensions.
>>
>>
>> To clarify, loading them directly into <FF/TB install>/extensions is
>> going away, and the "as normal extensions" deployment means loading into
>> distribution/extensions, where they are copied into and then run from
>> the user profile?
>>
>>
>>
>> On Fri, Nov 1, 2019 at 8:59 AM Mike Kaply <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On Fri, Nov 1, 2019 at 10:39 AM Stephen Dowdy <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On 11/1/19 9:21 AM, Mike Kaply wrote:
>> > You can deploy extensions as a part of Firefox by putting them
>> in the distribution/extensions directory and then locking them
>> via policy.
>> >
>> > This has always been a better way then putting them in system
>> directories where they might not get updated properly.
>>
>> Mike, i composed the below before this current response from you
>> came out, but it
>> sounds like, firefox will STILL support APPDIR extensions
>> deployment, but not user
>> PROFDIR deployments (this changes the extensions.*scopes
>> preferences functionality
>> i would assume.) So, is there a guide on how the old-school
>> stuff should now be
>> done with Policies?
>>
>>
>> The thing that is going away is the concept of sideloading where you
>> put extensions in a central location and they get loaded into
>> Firefox and the user can't remove them (they can only disable them).
>>
>> You will still be able to put extensions into
>> distribution/extensions because they simply get installed into
>> Firefox as normal extensions.
>>
>>
>>
>> To be blunt: I really still am puzzled by the entire Policies
>> thing, as the autoconfig
>> stuff (to me) seems to be more useful/functional and stuff like
>> locking/defaulting
>> Policies was bolted on after it was discovered they didn't offer
>> the same functionality
>> of defaultPref() lockPref() etc... (i.e. it seems to be playing
>> catchup rather than
>> offering me something of value. Security? Maintainability? ?)
>>
>>
>> autoconfig for setting/locking preferences continues to be available
>> and will always be available. The only thing being locked down in
>> autoconfig on release (not ESR) is the fact that you could use
>> autoconfig to bypass Firefox security and access everything in
>> Firefox (this is how the CCK2 works).
>>
>> The reason I haven't made every preference available in policy is:
>>
>> 1. There are way too many preferences.
>> 2. Folks change a ton of preferences without having any idea what
>> they do.
>>
>> I still ponder this every so often, but then I see some of the
>> preferences people change and bang my head against a wall.
>>
>> If there are prefs you need, please let me know.
>>
>>
>>
>> There seems to be a lot of chaos for what i don't see as a
>> benefit. It appears a lot
>> of us are getting frustrated over having to bang our heads on
>> just maintaining status-quo
>> operations, and if there is some well-defined reasoning, getting
>> some better P.R.
>> out on that might help. (for me, the camel that broke my back
>> was removing 'user.js'
>> functionality for one freakin' stat() call of "performance".
>> this is just insane)
>> (i have been cursing Mozilla for the past year over these types
>> of things, though)
>>
>>
>> I don't think user.js has been removed yet, has it?
>>
>> user.js isn't just about performance. We've seen malware using
>> user.js to do some serious hijacking of Firefox.
>>
>> A lot of what we do is in the interest of protecting users. Folks
>> don't see all the terrible ways these various mechanisms are used to
>> ruin user experience.
>>
>> By moving to policies, we can have a standard way to do things and
>> stop the hodgepodge we had before (which I largely created).
>>
>>
>>
>>
>> I really appreciate you *personally* being so engaged and
>> responsive, however. So
>> a big Thank You for that.
>>
>>
>> Thanks
>>
>> Mike
>>
>>
>>
>> --stephen
>>
>>
>> ----- (previously composed message) -----
>>
>> This is totally unclear to me what's happening (from the blog
>> post). Does this
>> apply to the APPDIR 'extensions' folders? (it seems clear it
>> applies to PROFDIR
>> extensions folders). If so, PLEASE tell me how i am supposed to
>> support an
>> enterprise install that has preloaded extensions in a SYSADMIN
>> controlled space?
>> (at least for linux)
>>
>> I don't presently do this for *firefox*, but i do for
>> 'thunderbird' (yeah,
>> the announcement doesn't say tbird, but i presume it'll hit
>> there sometime) I
>> load 'mailredirect' because thunderbird fails to offer that
>> function. (into
>> /usr/local/thunderbird/extensions/{..}.xpi) and presently, until
>> 'enigmail' is
>> replaced by builtin PGP functionality, i add that, too.
>>
>> Replacing a programmatic install with site-selected addons with
>> a request for interactive action:
>> "Hey, user, please go to A.M.O. and download this addon
>> after you start the app the first time",
>> is totally untenable.
>>
>>
>> thanks,
>> --stephen
>> _______________________________________________
>> Enterprise mailing list
>> [email protected] <mailto:[email protected]>
>> https://mail.mozilla.org/listinfo/enterprise
>>
>> To unsubscribe from this list, please visit
>> https://mail.mozilla.org/listinfo/enterprise or send an email to
>> [email protected]
>> <mailto:[email protected]> with a subject of
>> "unsubscribe"
>>
>> _______________________________________________
>> Enterprise mailing list
>> [email protected] <mailto:[email protected]>
>> https://mail.mozilla.org/listinfo/enterprise
>>
>> To unsubscribe from this list, please visit
>> https://mail.mozilla.org/listinfo/enterprise or send an email to
>> [email protected]
>> <mailto:[email protected]> with a subject of "unsubscribe"
>>
>>
>> _______________________________________________
>> Enterprise mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/enterprise
>>
>> To unsubscribe from this list, please visit
>> https://mail.mozilla.org/listinfo/enterprise or send an email to
>> [email protected] with a subject of "unsubscribe"
>>
>
--
結城 洋志 <YUKI Hiroshi>
E-mail: [email protected]
WWW : http://www.clear-code.com/
_______________________________________________
Enterprise mailing list
[email protected]
https://mail.mozilla.org/listinfo/enterprise
To unsubscribe from this list, please visit
https://mail.mozilla.org/listinfo/enterprise or send an email to
[email protected] with a subject of "unsubscribe"
