I had an unexpected system shutdown over the weekend that resulted in a
corrupted logins.json file in my SeaMonkey profile. I restored an older
version of this file and have worked around most of the issues resulting
from this, Provider for Google Calendar keeps asking to sign in!

Prior to this crash Provider for Google Calendar simply worked. Since
this crash I keep getting a pop-up window that it needs me to sign into
Google every few minutes! This is especially annoying as the window
insists on remaining on top which makes it difficult to reach the saved
logins tab to copy the password. It also requires a two step
verification that I mus do from my phone despite having checked the box
to not require this again and repeatedly allow access.

My Google account shows that access has been granted since February 4,
2023 and thus this should not be happening.

I have to guess I have lost something else in the profile that is not
being set properly when I log the extension in.

How do I fix this?

Dave

David H Durgee wrote:
> I had an unexpected system shutdown over the weekend that resulted in a
> corrupted logins.json file in my SeaMonkey profile.  I restored an older
> version of this file and have worked around most of the issues resulting
> from this, Provider for Google Calendar keeps asking to sign in!
>
> Prior to this crash Provider for Google Calendar simply worked.  Since
> this crash I keep getting a pop-up window that it needs me to sign into
> Google every few minutes!  This is especially annoying as the window
> insists on remaining on top which makes it difficult to reach the saved
> logins tab to copy the password.  It also requires a two step
> verification that I mus do from my phone despite having checked the box
> to not require this again and repeatedly allow access.
>
> My Google account shows that access has been granted since February 4,
> 2023 and thus this should not be happening.
>
> I have to guess I have lost something else in the profile that is not
> being set properly when I log the extension in.
>
> How do I fix this?
>

I have done a bit more looking into this problem and believe that it is
caused by the extension failing to save the OAuth token in logins.json
for some reason.

Looking into the extensions code I see in gdataSession.jsm:

// Overwrite the refreshToken attribute, since we want to save it in
// the password manager
let pwMgrId = "Google Calendar OAuth Token";

and later:

set: function(val) {
f (Preferences.get("signon.rememberSignons")) {
try {
let origin = "oauth:" + sessionId;
if (val) {
cal.auth.passwordManagerSave(sessionId, val, origin, pwMgrId);
} else {
cal.auth.passwordManagerRemove(sessionId, origin, pwMgrId);
}

So for some reason the OAuth is not being saved.

Surprisingly the logins.json I retrieved and replaced the corrupted one
with DID have that token present, but I guess it was expired or
otherwise invalidated and removed and not replaced.

I thought I might be able to manually add it back in, but the 400k
logins.json file is too big for my usual editor to work with.

Any suggestions on fixing this?

Dave

On 18/03/2024 23:00, David H Durgee wrote:
>...
> I thought I might be able to manually add it back in, but the 400k
> logins.json file is too big for my usual editor to work with.

There is a an editor in SM dev tools (Shift+F4, or Tools>Web
development>Scratchpad). That should be capable of editing a copy of the
file, using the right character set and newline character. It has a
pretty-printer too, to help you see the JSON structure.

/df

--
London
UK

Dirk Fieldhouse wrote:
> On 18/03/2024 23:00, David H Durgee wrote:
>> ...
>> I thought I might be able to manually add it back in, but the 400k
>> logins.json file is too big for my usual editor to work with.
>
> There is a an editor in SM dev tools (Shift+F4, or Tools>Web
> development>Scratchpad). That should be capable of editing a copy of the
> file, using the right character set and newline character. It has a
> pretty-printer too, to help you see the JSON structure.
>
> /df

Thank you for the pointer. I was able to use that editor to add the
OAuth entry to logins.json and when I restarted SeaMonkey I did not get
the request to login for the provider.

Interestingly, when I took a look at Saved Logins I did NOT see it
displayed. Inspecting logins.json likewise showed that it had been
removed. Strange.

Unfortunately I started getting the login requests again about 12 hours
after I restarted SeaMonkey and I just got another one about an hour
after that.

I am completely puzzled by this and have no idea what to do next.

Dave

On 19/03/2024 18:41, David H Durgee wrote:
>...
>
> Interestingly, when I took a look at Saved Logins I did NOT see it
> displayed.  Inspecting logins.json likewise showed that it had been
> removed.  Strange.
>
> Unfortunately I started getting the login requests again about 12 hours
> after I restarted SeaMonkey and I just got another one about an hour
> after that.

When I wrote "editing a copy of the file", it was shorthand for
- close SM
- make a copy of the file
- edit the copy in SM Scratchpad
- close SM
- replace the file with the edited copy
- start SM
- profit?

Otherwise SM will overwrite the file with its internal version that you
can't change. But maybe you already divined the idea and there is a
further issue.

/df

--
London
UK

Dirk Fieldhouse wrote:
> On 19/03/2024 18:41, David H Durgee wrote:
>> ...
>>
>> Interestingly, when I took a look at Saved Logins I did NOT see it
>> displayed.  Inspecting logins.json likewise showed that it had been
>> removed.  Strange.
>>
>> Unfortunately I started getting the login requests again about 12 hours
>> after I restarted SeaMonkey and I just got another one about an hour
>> after that.
>
> When I wrote "editing a copy of the file", it was shorthand for
> - close SM
> - make a copy of the file
> - edit the copy in SM Scratchpad
> - close SM
> - replace the file with the edited copy
> - start SM
> - profit?
>
> Otherwise SM will overwrite the file with its internal version that you
> can't change. But maybe you already divined the idea and there is a
> further issue.
>

I followed your outline above, so that is why I am puzzled. The active
login.json file still shows the updated "nextId" that I had to update to
add the additional entry, but the final entry I added has been removed.
Perhaps the extension removed it as it was expired? Why then wasn't a
new one saved? Are there any size limits to login.json?

I thought it was strange that it was removed, but then when I stopped
getting the login requests I thought I was out of trouble.
Unfortunately it started back up after 12 hours.

It appears from the extension code that logging is included, perhaps
enabling it would give me an idea of what is going wrong? If so, should
I try the basic or verbose level? Should I insert the OAuth entry again
or leave it out?

Any other ideas?

Would perhaps disabling and then enabling would help? Remove and reinstall?

Dave

David H Durgee wrote:
> Dirk Fieldhouse wrote:
>> On 19/03/2024 18:41, David H Durgee wrote:
>>> ...
>>>
>>> Interestingly, when I took a look at Saved Logins I did NOT see it
>>> displayed.  Inspecting logins.json likewise showed that it had been
>>> removed.  Strange.
>>>
>>> Unfortunately I started getting the login requests again about 12 hours
>>> after I restarted SeaMonkey and I just got another one about an hour
>>> after that.
>>
>> When I wrote "editing a copy of the file", it was shorthand for
>> - close SM
>> - make a copy of the file
>> - edit the copy in SM Scratchpad
>> - close SM
>> - replace the file with the edited copy
>> - start SM
>> - profit?
>>
>> Otherwise SM will overwrite the file with its internal version that you
>> can't change. But maybe you already divined the idea and there is a
>> further issue.
>>
>
> I followed your outline above, so that is why I am puzzled.  The active
> login.json file still shows the updated "nextId" that I had to update to
> add the additional entry, but the final entry I added has been removed.
> Perhaps the extension removed it as it was expired?  Why then wasn't a
> new one saved?  Are there any size limits to login.json?
>
> I thought it was strange that it was removed, but then when I stopped
> getting the login requests I thought I was out of trouble. Unfortunately
> it started back up after 12 hours.
>
> It appears from the extension code that logging is included, perhaps
> enabling it would give me an idea of what is going wrong?  If so, should
> I try the basic or verbose level?  Should I insert the OAuth entry again
> or leave it out?
>
> Any other ideas?
>
> Would perhaps disabling and then enabling would help?  Remove and
> reinstall?
>
> Dave

Removing and reinstalling almost never helps (and the "almost" is
debatable), the program is separate from the profile and your problem is
in the profile.

Don Vito Martinelli wrote:
> David H Durgee wrote:
>> Dirk Fieldhouse wrote:
>>> On 19/03/2024 18:41, David H Durgee wrote:
>>>> ...
>>>>
>>>> Interestingly, when I took a look at Saved Logins I did NOT see it
>>>> displayed.  Inspecting logins.json likewise showed that it had been
>>>> removed.  Strange.
>>>>
>>>> Unfortunately I started getting the login requests again about 12 hours
>>>> after I restarted SeaMonkey and I just got another one about an hour
>>>> after that.
>>>
>>> When I wrote "editing a copy of the file", it was shorthand for
>>> - close SM
>>> - make a copy of the file
>>> - edit the copy in SM Scratchpad
>>> - close SM
>>> - replace the file with the edited copy
>>> - start SM
>>> - profit?
>>>
>>> Otherwise SM will overwrite the file with its internal version that you
>>> can't change. But maybe you already divined the idea and there is a
>>> further issue.
>>>
>>
>> I followed your outline above, so that is why I am puzzled.  The
>> active login.json file still shows the updated "nextId" that I had to
>> update to add the additional entry, but the final entry I added has
>> been removed. Perhaps the extension removed it as it was expired?  Why
>> then wasn't a new one saved?  Are there any size limits to login.json?
>>
>> I thought it was strange that it was removed, but then when I stopped
>> getting the login requests I thought I was out of trouble.
>> Unfortunately it started back up after 12 hours.
>>
>> It appears from the extension code that logging is included, perhaps
>> enabling it would give me an idea of what is going wrong?  If so,
>> should I try the basic or verbose level?  Should I insert the OAuth
>> entry again or leave it out?
>>
>> Any other ideas?
>>
>> Would perhaps disabling and then enabling would help?  Remove and
>> reinstall?
>>
>> Dave
>
> Removing and reinstalling almost never helps (and the "almost" is
> debatable), the program is separate from the profile and your problem is
> in the profile.

That was my thought as well, since the installed extension is simply the
xpi file copied and renamed in the extensions sub-directory and unzip -t
confirms that the file has not been damaged. The only possibility I
could this of that the remove/install might do would be to recreate a
missing profile element.

I am more hopeful of the logging, but it has been so long since I used
it with SeaMonkey I don't recall how to tell it where to place the log
file. I think I have to start from a linux terminal window, but there
might be an alternative way to accomplish this.

Dave

David H Durgee wrote on 20/03/2024 6:47 am:
> Dirk Fieldhouse wrote:
>> On 19/03/2024 18:41, David H Durgee wrote:
>>> ...
>>>
>>> Interestingly, when I took a look at Saved Logins I did NOT see it
>>> displayed.  Inspecting logins.json likewise showed that it had been
>>> removed.  Strange.
>>>
>>> Unfortunately I started getting the login requests again about 12 hours
>>> after I restarted SeaMonkey and I just got another one about an hour
>>> after that.
>>
>> When I wrote "editing a copy of the file", it was shorthand for
>> - close SM
>> - make a copy of the file
>> - edit the copy in SM Scratchpad
>> - close SM
>> - replace the file with the edited copy
>> - start SM
>> - profit?
>>
>> Otherwise SM will overwrite the file with its internal version that you
>> can't change. But maybe you already divined the idea and there is a
>> further issue.
>
> I followed your outline above, so that is why I am puzzled.  The active
> login.json file still shows the updated "nextId" that I had to update to
> add the additional entry, but the final entry I added has been removed.
> Perhaps the extension removed it as it was expired?  Why then wasn't a
> new one saved?  Are there any size limits to login.json?

Might the login.json be marked as 'Read Only'??

> I thought it was strange that it was removed, but then when I stopped
> getting the login requests I thought I was out of trouble. Unfortunately
> it started back up after 12 hours.
>
> It appears from the extension code that logging is included, perhaps
> enabling it would give me an idea of what is going wrong?  If so, should
> I try the basic or verbose level?  Should I insert the OAuth entry again
> or leave it out?
>
> Any other ideas?
>
> Would perhaps disabling and then enabling would help?  Remove and
> reinstall?
>
> Dave

If you were to close SM (completely i.e. closing the 'Quick Start'
function as well) after about 11 hours (i.e. some time shorter that your
'12' hours), might that fix things .... or does it, again, re-occur
after about 12 hours??
--
Daniel

Daniel65 wrote:
> David H Durgee wrote on 20/03/2024 6:47 am:
>> Dirk Fieldhouse wrote:
>>> On 19/03/2024 18:41, David H Durgee wrote:
>>>> ...
>>>>
>>>> Interestingly, when I took a look at Saved Logins I did NOT see it
>>>> displayed.  Inspecting logins.json likewise showed that it had been
>>>> removed.  Strange.
>>>>
>>>> Unfortunately I started getting the login requests again about 12 hours
>>>> after I restarted SeaMonkey and I just got another one about an hour
>>>> after that.
>>>
>>> When I wrote "editing a copy of the file", it was shorthand for
>>> - close SM
>>> - make a copy of the file
>>> - edit the copy in SM Scratchpad
>>> - close SM
>>> - replace the file with the edited copy
>>> - start SM
>>> - profit?
>>>
>>> Otherwise SM will overwrite the file with its internal version that you
>>> can't change. But maybe you already divined the idea and there is a
>>> further issue.
>>
>> I followed your outline above, so that is why I am puzzled.  The
>> active login.json file still shows the updated "nextId" that I had to
>> update to add the additional entry, but the final entry I added has
>> been removed. Perhaps the extension removed it as it was expired?  Why
>> then wasn't a new one saved?  Are there any size limits to login.json?
>
> Might the login.json be marked as 'Read Only'??
>
>> I thought it was strange that it was removed, but then when I stopped
>> getting the login requests I thought I was out of trouble.
>> Unfortunately it started back up after 12 hours.
>>
>> It appears from the extension code that logging is included, perhaps
>> enabling it would give me an idea of what is going wrong?  If so,
>> should I try the basic or verbose level?  Should I insert the OAuth
>> entry again or leave it out?
>>
>> Any other ideas?
>>
>> Would perhaps disabling and then enabling would help?  Remove and
>> reinstall?
>>
>> Dave
>
> If you were to close SM (completely i.e. closing the 'Quick Start'
> function as well) after about 11 hours (i.e. some time shorter that your
> '12' hours), might that fix things .... or does it, again, re-occur
> after about 12 hours??

Is "Quick Start" still an option? I last had that activated around 25
years ago and thought it no longer existed, at least for Linux - which
is what DHD is using.
Having looked at the configuration options, I can't see how to set it or
clear it (I only looked at the "Appearance" and "Advanced" sections).

On 2024-03-19, David H Durgee wrote:

> Dirk Fieldhouse wrote:
>> On 18/03/2024 23:00, David H Durgee wrote:
>>> ...
>>> I thought I might be able to manually add it back in, but the 400k
>>> logins.json file is too big for my usual editor to work with.
>>
>> There is a an editor in SM dev tools (Shift+F4, or Tools>Web
>> development>Scratchpad). That should be capable of editing a copy of the
>> file, using the right character set and newline character. It has a
>> pretty-printer too, to help you see the JSON structure.
>>
>> /df
>
> Thank you for the pointer. I was able to use that editor to add the
> OAuth entry to logins.json and when I restarted SeaMonkey I did not
> get the request to login for the provider.
>
> Interestingly, when I took a look at Saved Logins I did NOT see it
> displayed. Inspecting logins.json likewise showed that it had been
> removed. Strange.
>
> Unfortunately I started getting the login requests again about 12
> hours after I restarted SeaMonkey and I just got another one about an
> hour after that.
>
> I am completely puzzled by this and have no idea what to do next.
>
> Dave

This is without direct experience and only from memory, might not be
accurate or not be helpful at all, but: wasn't there something about
(temporarily?) having to allow cookies and/or javascript for this kind
of OAuth2 login?

Or did the cookie jar/store survive the incident?

--
Nuno Silva

Nuno Silva wrote:
> On 2024-03-19, David H Durgee wrote:
>
>> Dirk Fieldhouse wrote:
>>> On 18/03/2024 23:00, David H Durgee wrote:
>>>> ...
>>>> I thought I might be able to manually add it back in, but the 400k
>>>> logins.json file is too big for my usual editor to work with.
>>>
>>> There is a an editor in SM dev tools (Shift+F4, or Tools>Web
>>> development>Scratchpad). That should be capable of editing a copy of the
>>> file, using the right character set and newline character. It has a
>>> pretty-printer too, to help you see the JSON structure.
>>>
>>> /df
>>
>> Thank you for the pointer. I was able to use that editor to add the
>> OAuth entry to logins.json and when I restarted SeaMonkey I did not
>> get the request to login for the provider.
>>
>> Interestingly, when I took a look at Saved Logins I did NOT see it
>> displayed. Inspecting logins.json likewise showed that it had been
>> removed. Strange.
>>
>> Unfortunately I started getting the login requests again about 12
>> hours after I restarted SeaMonkey and I just got another one about an
>> hour after that.
>>
>> I am completely puzzled by this and have no idea what to do next.
>>
>> Dave
>
> This is without direct experience and only from memory, might not be
> accurate or not be helpful at all, but: wasn't there something about
> (temporarily?) having to allow cookies and/or javascript for this kind
> of OAuth2 login?
>
> Or did the cookie jar/store survive the incident?
>

When I set up my Gmail access in Seamonkey - after they changed the
requirements - and tried to "Get Msgs", a popup appeared and I had to
explicitly permit it to get OAuth2 working correctly. Once I'd done
that everything worked without popups.
One exception: I occasionally copy my Seamonkey profiles to another
machine, I think I have a similar problem there when using Gmail for the
first time.

Don Vito Martinelli wrote on 20/3/24 8:19 pm:
> Daniel65 wrote:
>> David H Durgee wrote on 20/03/2024 6:47 am:
>>> Dirk Fieldhouse wrote:
>>>> On 19/03/2024 18:41, David H Durgee wrote:
>>>>> ...
>>>>>
>>>>> Interestingly, when I took a look at Saved Logins I did NOT
>>>>> see it displayed. Inspecting logins.json likewise showed
>>>>> that it had been removed. Strange.
>>>>>
>>>>> Unfortunately I started getting the login requests again
>>>>> about 12 hours after I restarted SeaMonkey and I just got
>>>>> another one about an hour after that.
>>>>
>>>> When I wrote "editing a copy of the file", it was shorthand
>>>> for - close SM - make a copy of the file - edit the copy in SM
>>>> Scratchpad - close SM - replace the file with the edited copy -
>>>> start SM - profit?
>>>>
>>>> Otherwise SM will overwrite the file with its internal version
>>>> that you can't change. But maybe you already divined the idea
>>>> and there is a further issue.
>>>
>>> I followed your outline above, so that is why I am puzzled. The
>>> active login.json file still shows the updated "nextId" that I
>>> had to update to add the additional entry, but the final entry I
>>> added has been removed. Perhaps the extension removed it as it
>>> was expired? Why then wasn't a new one saved? Are there any size
>>> limits to login.json?
>>
>> Might the login.json be marked as 'Read Only'??
>>
>>> I thought it was strange that it was removed, but then when I
>>> stopped getting the login requests I thought I was out of
>>> trouble. Unfortunately it started back up after 12 hours.
>>>
>>> It appears from the extension code that logging is included,
>>> perhaps enabling it would give me an idea of what is going wrong?
>>> If so, should I try the basic or verbose level? Should I insert
>>> the OAuth entry again or leave it out?
>>>
>>> Any other ideas?
>>>
>>> Would perhaps disabling and then enabling would help? Remove and
>>> reinstall?
>>>
>>> Dave
>>
>> If you were to close SM (completely i.e. closing the 'Quick Start'
>> function as well) after about 11 hours (i.e. some time shorter
>> that your '12' hours), might that fix things .... or does it,
>> again, re-occur after about 12 hours??
>
> Is "Quick Start" still an option? I last had that activated around
> 25 years ago and thought it no longer existed, at least for Linux -
> which is what DHD is using.

Sorry! I thought I read that David was Dual-Booting Windows and Linux.

> Having looked at the configuration options, I can't see how to set it
> or clear it (I only looked at the "Appearance" and "Advanced"
> sections).

I didn't know it was ever a thing in Linux, just in Windows.
--
Daniel

Nuno Silva wrote:
> On 2024-03-19, David H Durgee wrote:
>
>> Dirk Fieldhouse wrote:
>>> On 18/03/2024 23:00, David H Durgee wrote:
>>>> ...
>>>> I thought I might be able to manually add it back in, but the 400k
>>>> logins.json file is too big for my usual editor to work with.
>>>
>>> There is a an editor in SM dev tools (Shift+F4, or Tools>Web
>>> development>Scratchpad). That should be capable of editing a copy of the
>>> file, using the right character set and newline character. It has a
>>> pretty-printer too, to help you see the JSON structure.
>>>
>>> /df
>>
>> Thank you for the pointer. I was able to use that editor to add the
>> OAuth entry to logins.json and when I restarted SeaMonkey I did not
>> get the request to login for the provider.
>>
>> Interestingly, when I took a look at Saved Logins I did NOT see it
>> displayed. Inspecting logins.json likewise showed that it had been
>> removed. Strange.
>>
>> Unfortunately I started getting the login requests again about 12
>> hours after I restarted SeaMonkey and I just got another one about an
>> hour after that.
>>
>> I am completely puzzled by this and have no idea what to do next.
>>
>> Dave
>
> This is without direct experience and only from memory, might not be
> accurate or not be helpful at all, but: wasn't there something about
> (temporarily?) having to allow cookies and/or javascript for this kind
> of OAuth2 login?
>
> Or did the cookie jar/store survive the incident?

I use OAuth with the OMAP servers for six email accounts and none of
them have this problem. Opening the cookie manager I see many cookies
associated with google.com, so that does not seem to be the problem.

Dave