MainSoft's dashboard

Hi Colin,

By the way, I have added the -u and -p switches to the command stored in the Run | XMarks key value of the registry but they were wiped out when installing the latest version. The installer should take care of what is already present in this value, I guess.

--
Patrick – MainSoft, on November 18, 2009 11:09

Hi Colin,

This workaround fixes the problem for me. Now, you have to find the real cause of this behavior. I have tried to investigate this case but couldn't find any reason for which the autologon doesn't work on some systems.

Cheers.

--
Patrick

OK. Thanks Colin.

--
Patrick

Hi,

More information about this issue...

I could determine that when XMarks for IE stores the credentials locally via the CredUI API, it stores them in this file:

C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Credentials\<user_sid>\Credentials (a file without any filename extension)

To be sure, I deleted the Credentials folder entirely. When I entered the credentials again I could see that the file was re-created normally. So there is no permission or file corruption problem when the credentials are cached.

However, after a reboot, XMarks still didn't retrieve the credentials and asked for them again. I could observe that when I re-entered the credentials, they were stored again (the "last modification" timestamp was changed) but the "last access" timestamp never changes. Apparently, the file is never read.

So it seems that when XMarks starts, just after the login, it cannot access the credentials file in the user profile folder (of course, I checked the permissions). Since the problem also occurs when the laptop is connected through a cable and not wireless, I guess the wireless connection is not involved).

At least it's now obvious that the problem is not that XMarks cannot cache the credentials. It does. Just, it cannot re-read them when starting up.

This also demonstrates that the "Stored Usernames and Passwords" fix cannot work because this tool usually stores the credentials elsewhere (in the Protected Storage). But I'm not sure that this is true on all systems.

For what it's worth...

--
Patrick</user_sid></user>

Colin,

> My gut feeling is that there is some sort of permissions
> issue with Windows that is allowing applications to write
> to the Windows password store

I can assure you that I have checked all possibly related permissions. Now, if you could tell me what specific registry or folder items should be checked, this could certainly help.

--
Patrick

Hi Colin,

The code that I wrote for one of my two test programs is almost exactly the same and, as previously mentioned, the system is not returning any error when calling CredWrite. Following are the contents of the log file (starting from a clear log, logging in, rebooting, and finally logging in again because the credentials were not remembered:


Wed Aug 12 08:58:04 2009: -------- Xmarks Favorites Sync: log file cleared --------
Wed Aug 12 08:58:11 2009: Attaching observers
Wed Aug 12 08:58:31 2009: Logged on as MyUserName
Wed Aug 12 08:58:31 2009: New SyncRequest Initialized [POST]: https://login.xmarks.com/login/signtoken (cleaned body: {"log":{"mid":"kgwgkn"},"manual":true,"username":"MyUserName"}
)
Wed Aug 12 08:58:33 2009: Cleaned SyncRequest response from server: {
"status" : 0
}

Wed Aug 12 08:58:35 2009: Attaching observers
Wed Aug 12 08:58:44 2009: -------- Xmarks Favorites Sync is shutting down; turning off logging --------
Wed Aug 12 09:01:49 2009: -------- New Xmarks Favorites Sync instance started --------
Wed Aug 12 09:01:49 2009: Using localized name [Liens], loaded from [Software\Microsoft\Internet Explorer\Toolbar]
Wed Aug 12 09:01:49 2009: Xmarks [1.0.11], Windows version [5.1], UAC enabled [false], IE version [8.0.6001.18702]
Wed Aug 12 09:01:49 2009: Couldn't find filter function [127], unable to unfilter outside messagse
Wed Aug 12 09:01:49 2009: Attaching observers
Wed Aug 12 09:03:35 2009: Attaching observers
Wed Aug 12 09:03:57 2009: Logged on as MyUserName
Wed Aug 12 09:03:57 2009: New SyncRequest Initialized [POST]: https://login.xmarks.com/login/signtoken (cleaned body: {"log":{"mid":"kgwgkn"},"manual":true,"username":"MyUserName"}
)
Wed Aug 12 09:03:58 2009: Cleaned SyncRequest response from server: {
"status" : 0
}


#1
The problem actually occurs when XMarks tries to read the cached credentials when it is automatically started after a reboot. On all other systems that we have here, the XMarks login is done automatically because XMarks is able to find the cached credentials. Not on that particular system. So the question is either "Were the credential not cached?" OR "Are they actually cached and XMarks cannot read them for any reason?".

#2
As I already explained, the XMarks credentials **never** appear in "Stored Usernames and Passwords", even on those systems where there's no problem. So the fact that I cannot see the credentials in "Stored Usernames and Passwords" on the system were I have the problem is not an evidence that the credentials have not been stored.

#3
Your code is using the CRED_PERSIST_LOCAL_MACHINE flag. Are you aware that (excerpt from the MSDN documentation:

"
[on] Windows Vista Home Basic, Windows Vista Home Premium, Windows Vista Starter, and Windows XP Home Edition: This value is not supported.
"

So what are you doing in this case?

So, as someone commented earlier, an alternate way of storing the credentials might be a better choice. Or see #6.

#4
I guess that XMarks is reading the cached credentials when starting up by using the CredRead API. Are you also logging possible errors at this time? Actually, this is certainly then that interesting things are happening. So it would be interesting to have a look at the code used to read the cached credentials and see whether there's an error during this process and what XMarks does in that case.

#5
Your code sample mentions "www.xmarks.com" as the target. Until now, when you suggested to manually create the entry in Stored Usernames and Passwords, you always indicated "login.xmarks.com" as the target. Which is the correct one?

#6
Your code indicates that you are using CredWrite to store the credentials. However, in order to retrieve them, you are also using CredUIpromptForCredentials dialog box which is also able to persist the credentials (just use the CREDUI_FLAGS_EXPECT_CONFIRMATION flag and call CredUIConfirmCredentials once the credentials have been validated). CredUIPromptForCredentials doesn't have the same limitations regarding the flags mentioned above in #3. So I don't see the need for a call to CredWrite anyway.

My two cents...

--
Patrick

Hi,

So I have written a small program using the same API as XMarks for IE to create and store my XMarks credentials on the system. I have used two different methods to do this, one being probably the same one as XMarks for IE uses.

In both cases, the credentials were created normally but didn't survive a reboot. No error was reported by the system. So I guess it's not a problem with XMarks for IE itself.

I have researched all situations that could cause a specific set of credentials to be cleared after a reboot. To no avail (although this is a problem that seems to occur rather often). Note that on my system, other credentials are stored permanently without any problem.

So maybe it's related to the domain itself (login.xmarks.com).

I think I'll give up soon :-)

--
Patrick

Answering my own questions:

XMarks for IE uses the CREDUI API to retrieve and store the credentials. So I'll try to write a small test program in order to determine why these credentials are not stored permanently on certain systems.

--
Patrick

Hi Nate,

>Do you have any settings that are removing private data from IE?

By the way, what has IE to do with this issue? XMarks for IE is supposed to use the Protected Storage to save the credentials. How could an IE setting interfere?

--
Patrick – MainSoft, on July 28, 2009 11:27

Nate,

I'm not the only one with this problem, obviously. It happens only on one system here. Just to be sure, I have reset the group policy and security settings on this system and this didn't help. Please read this thread cautiously:

http://getsatisfaction.com/foxmarks/t...

Some questions I have asked to Colin remained unanswered. If I only had informations about what Xmarks for IE is exactly doing when storing the credentials, I could try to track down the problem (I'm a developer).

Also, I'm not aware of any IE setting that could be the cause of this issue. Do you know one?

Regards.

Hi Colin,

Your comments do not apply to Windows XP because in that case, KeyMgr has no "Credential Type" option. So when entering the username, KeyMgr complains because it wants something like domain\username or username@domain.

So this trick doesn't work with XP and the problem is still there which is very annoying.

Regards.

--
Patrick – MainSoft, on July 13, 2009 21:08

Hi,

FYI. The problem is not fixed by version 1.0.11.

--
Patrick

Sorry, the problem is back after a reboot.

--
Patrick

Hi Colin,

I'm not sure you really understood what I said :-) : on the systems ***where I don't have the problem***, when I open the Windows Password Manager, ***there's no (visible) entry related to xmarks.com or foxmarks.com***. Nothing. Nada. However, XMarks for IE automatically logs on and synchronizes when started on these systems **without prompting me to logon***. Never. So I guess the credentials are stored elsewhere or the related entry in the Password Manager is hidden. In both cases, we can't see it, contrary to what was suggested in your other thread..

I did what you suggested in your previous message. Here is what I found in the log file:

===========================================
Tue May 12 10:09:24 2009: -------- New Xmarks Favorites Sync instance started --------
Tue May 12 10:09:24 2009: Using localized name [Liens], loaded from [Software\Microsoft\Internet Explorer\Toolbar]
Tue May 12 10:09:24 2009: Xmarks [1.0.10], Windows version [5.1], UAC enabled [false], IE version [8.0.6001.18702]
Tue May 12 10:09:24 2009: Couldn't find filter function [127], unable to unfilter outside messagse
Tue May 12 10:09:32 2009: Starting synchronization
Tue May 12 10:09:32 2009: Reading baseline
Tue May 12 10:09:32 2009: Reading NodeSet from disk: C:\Documents and Settings\PatAsus\Local Settings\Application Data\Xmarks\xmarks-baseline.json
Tue May 12 10:09:32 2009: Error loading baseline file: FoxmarksException [500]: Baseline's hash [PatTheUser@xmarks.com] does not match current user [@xmarks.com]
Tue May 12 10:09:32 2009: New SyncRequest Initialized [POST]: http://sync.xmarks.com/sync/bookmarks... (cleaned body: {"depth":"all","log":{"mid":"kgwgkn"},"manual":true,"rev":"282","view":4}
)
Tue May 12 10:09:34 2009: Cleaned SyncRequest response from server: {
"authtoken_location" : "http://login.xmarks.com/login/signtoken",
"location" : "http://login.xmarks.com/login/sync",
"status" : 302
}

Tue May 12 10:09:49 2009: Logged on as PatTheUser
Tue May 12 10:09:49 2009: New SyncRequest Initialized [POST]: https://login.xmarks.com/login/signtoken (cleaned body: {"log":{"mid":"kgwgkn"},"manual":true,"username":"PatTheUser","view":4}
)
Tue May 12 10:09:50 2009: Cleaned SyncRequest response from server: {
"status" : 0
}

Tue May 12 10:09:50 2009: New SyncRequest Initialized [POST]: http://sync.xmarks.com/sync/bookmarks... (cleaned body: {"depth":"all","log":{"mid":"kgwgkn"},"manual":true,"rev":"282","view":4}
)
===========================================

The error related to the Baseline hash indicated that something was probably wrong with the credentials. So I decided to uninstall, delete the XMarks folder under Application Data and re-install.

This time, when I launched XMarks for IE the first time after re-installing, it logged in automatically but I got the following error:

===========================================
Xmarks
======

Help
Button3
An error occurred during synchronization. Please visit our help page for support.

Sync Error:

FoxmarksException during sync [1528] attempt: FoxmarksException [501]: Node not found: ROOT
===========================================

So I logged off from Windows and logged on again. This time XMarks for IE started and logged on automatically without prompting me for my credentials and synchronized without any error.

And guess what? There is still no visible entry related to xmarks in the Windows Password Manager, like on the 2 other systems :-) .

So the problem appears to be solved for me but there's obviously a bug somewhere.

Cheers.

--
Patrick

Hi,

>I already did what you suggested and the answer is yes,
>the synchronization works but I am prompted again later.
>This can happen hours later, though (during the same session).

Confirmed. I had the problem multiple times this week. XMarks for IE prompted me for my credentials at least twice during the same Windows session. And of course, it still doesn't remember these credentials.

>3. You said that my xmarks credentials should be stored in
>the Windows Password Manager and this is obviously not
>the case on the systems where the problem *doesn't* show
>up. So where are they stored?

I would appreciate an answer to this question. So I would be able to further investigate the system where the problem occurs. Thanks.

Cheers.

--
Patrick

Hi,

This problem also appeared today on one of my systems with Firefox. Although XMarks should have stored the PIN somewhere, it first asked me to re-enter it and then it rejected it multiple times (same message as in initial post). Since I was sure that the PIN was correct, I tried again after waiting a few minutes. And then the PIN was accepted.

--
Patrick

FYI.

I have the same version of keymgr.dll on all systems: 5.1.2600.5512 (04-14-2008). The latest XP updates have been applied.

--
Patrick