Author Topic: Discrepency with UrlComponents between FF plugin and web version  (Read 16961 times)

Offline landshark

  • Jr. Member
  • **
  • Posts: 19
Discrepency with UrlComponents between FF plugin and web version
« on: December 13, 2011, 04:00:40 AM »
While porting over "default account behavior" with jstapleton, we ran into a snag with how the FF plugin and the web-version parse the Url Components.

Take for example the url http://www.google.com/ig and having just "domain" and "Port, path..." selected.

The firefox plugin results in: google.com:/ig    (note the colon)
The web version results in: google.com/ig

This results in a different password being generated for each.

This is an interesting issue as there are now technically two default behaviors.

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Re: Discrepency with UrlComponents between FF plugin and web version
« Reply #1 on: December 13, 2011, 09:42:16 PM »
I think we can consider this a bug in the firefox plugin. The question is how to fix it. Previously, changes that break backwards compatibility were handled this way:

1. Introduce the fix
2. Provide a means for users to bypass the fix so their passwords aren't incorrectly generated when they upgrade to the latest version. You can see the legacy of this in the multiple versions of MD-5 offered as a hashing algorithm.

We can either go that route now, or take the riskier (but faster and cleaner) route of doing #1 without #2.

Thoughts?

How many people do we really think bother to check "Port, path, anchor, query parameters"?

eric

Offline landshark

  • Jr. Member
  • **
  • Posts: 19
Re: Discrepency with UrlComponents between FF plugin and web version
« Reply #2 on: December 16, 2011, 04:12:29 AM »
I didn't know those options even existed (I don't ever use the default account) until James let me know my default-account behavior was incorrect (fix in progress).  James made a patch for my code to implement much of the default behavior, at the same time I had been working on this but my implementation was incomplete.  I was using the firefox plugin as a base of comparison for testing my changes.  James was using the web-javascript version.  It was at that point we noticed that our behavior of ports was different and traced it back to the web and plugin differences.

The checkbox for "port, path, and query" could be changed to a checkbox with a listbox or set of radio buttons where the desired behavior could be selected (old/new).  Or you could just do away with it in hopes nobody selected it, but that could lock people out of an account.

Offline landshark

  • Jr. Member
  • **
  • Posts: 19
Re: Discrepency with UrlComponents between FF plugin and web version
« Reply #3 on: December 19, 2011, 08:42:11 PM »
Do you know what direction you want to take with this?

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3353
Re: Discrepency with UrlComponents between FF plugin and web version
« Reply #4 on: December 21, 2011, 04:24:47 PM »
I guess both old and new need to be supported, at least in the Firefox edition. I'll start working on it after the holidays. I don't think your edition needs to support both, do you?

eric

Offline landshark

  • Jr. Member
  • **
  • Posts: 19
Re: Discrepency with UrlComponents between FF plugin and web version
« Reply #5 on: December 21, 2011, 08:41:07 PM »
I guess both old and new need to be supported, at least in the Firefox edition. I'll start working on it after the holidays. I don't think your edition needs to support both, do you?

eric


I implemented the web version (no colon in empty ports).

PasswordMaker Forums

Re: Discrepency with UrlComponents between FF plugin and web version
« Reply #5 on: December 21, 2011, 08:41:07 PM »