Brian,
I probably wasn't clear with the wording of my suggestions. None of the
options I present require your users to do anything. Things would work with
a vanilla Safari browser for your users in each of them.
In option 1, the JustHumans servers will automatically notice that a user
isn't accepting cookies and rather than posting images that say "please
enable cookies" as it now does, it would automatically fall back to a less
secure form submission configuration. (ie: one that is guessable by a
computer)
Option 2 doesn't require your users to do anything. For this option, you (as
a user of JustHumans.com - my bad wording there) would add a DNS entry on
your DNS servers which would make a name within your domain resolve to the
JustHumans server IP. While it is less than flexible if JustHumans decides
to ever change server IPs, (hasn't happened yet) it is the only 100%
failsafe way to do this right now with JustHumans.
Option 3 would work for the same reason option 2 works. If you own the core
JustHumans code on your own servers, (not the JavaScript) that implies that
it runs under your own domain name and Safari will show the images.
To be clear, this is a browser problem with Safari. If Safari respected the
cookies that JustHumans sends, this wouldn't be an issue. The only way to
get Safari to accept cookies without your users setting something in Safari,
(which is clearly not a workable option) is to have everything under the
same domain.
For example, if you were running www.example.com, Safari currently sees
requests for cookies being sent from verify.justhumans.com. Safari, because
it is overly conservative in its default setting, decides not to return the
cookes that were requested and ends up with "Please enable cookies" images.
To fix this, you would need to create a DNS entry for
verify.example.comthat pointed to
verify.justhumans.com. When Safari runs into www.example.com, it sees
requests for cookies coming from verify.example.com instead. As those
requests are still within the domain example.com, Safari returns the cookies
and everything works as expected.
To be clear again, this is a problem with Safari, not JustHumans. I've coded
around many broken browser issues, even Internet Explorer's bizarre P3P
"Privacy Policy", but aside from selling the code or asking you to create a
DNS entry for verify.yoursite.com, this isn't something that I can get
around in code while retaining the security that JustHumans gives you.
That said though, I'm open to suggestions anyone has. I'm very interested in
fixing this for you guys but at this point it is hard to see how I could fix
it without requiring you guys to make a DNS modification to catch this
fringe case. I'm happy to talk through this with anyone who wants a better
explanation as well.
Thanks,
-Anders
On Mon, Apr 7, 2008 at 10:01 AM, EyeMagination-Brian <00davi...@gmail.com>
wrote:
> As you might know already, doing any options that require the user to
> modify their default settings just won't work. This is because we
> deal with potential clients, not just clients. So, option #1 & #2
> will not work. As for option #3, I'm not sure how adding code to our
> servers could help in this situation. I would think there needs to be
> a rewrite in code to make the code accessible to this issue. Maybe
> there might be an option for two different versions of this code?
> Regardless, I look for any new ways to resolve this issue.
> Thank you,
> Brian
> On Apr 5, 12:02 pm, Anders <ander...@gmail.com> wrote:
> > Brian,
> > What you are noticing here is an issue particular to Apple's Safari
> > web browser, not necessarily with the Mac in general. (ie: the same
> > behavior exists in Safari for Windows) In this case, Safari isn't
> > returning cookies to verify.justhumans.com because it thinks of it as
> > a third party site and not one you "requested" when you typed the URL
> > or clicked a link.
> > This is essentially a problem brought on because of an overly
> > conservative default cookie policy on Apple's part. To be fair though,
> > some cross site scripting attacks run by malicious websites are
> > significantly curtailed because of this setting in Safari so there is
> > some logic behind Apple doing this. This setting is also a problem for
> > other JavaScript based services such as Google's AdSense but it isn't
> > as obvious because for example Google doesn't rely on images being
> > shown.
> > Things we are considering to get around the Safari problem:
> > 1. Automatically fall back to a less secure (non cookie based)
> > verification process for browsers which don't support third party
> > cookies
> > 2. Ask our users to add a DNS entry for the verification server.
> > (difficult for people who are unfamiliar and don't run their own DNS
> > servers)
> > 3. Sell the code that runs JustHumans so it can be run locally to your
> > own servers
> > Obviously we're still working on this issue. I'll get back to the list
> > when we figure out what we will do to fix this.
> > Other browsers on the Mac (Firefox, Camino, Opera, etc.) don't have
> > this problem.
> > -Anders
> > On Apr 4, 2:44 pm, EyeMagination-Brian <00davi...@gmail.com> wrote:
> > > Hello Anders/JustHumans Group,
> > > I don't use a Mac, so I never noticed this problem. But, when I went
> > > to a client's office the other day, they had a Mac. The problem is
> > > the pictures won't show up on the contact form in the Mac version. We
> > > were looking at my site, for example:
> http://www.eyemagination.us/web_worksheet.asp.
> > > Is there any workaround this?
> > > Thanks,
> > > Brian Zajac
> > > EyeMagination- Hide quoted text -
> > - Show quoted text -
--
-Anders
-----------------------------------------------------------
Anders Brownworth
ander
...@gmail.com
