Private Sites not reachable now -

[Helmuti_pdorf]

ALL my private Sites and other private sites are unrechable now!

Even the admindevelopment.wikidot.com or pro.wikidot.com etc. - can
not be reached by me on my XP Sp3 in FF 2 or IE 7…

It is circuing between reading from

1. admindevelopment.wikidot.com -
2. admind............…..wdfiles.com .
back to 1…

What is ongoing now ?

to test I set all my firewall's off, deleted all cookies and internet
temp files ,
tried it with unlogged status (the login worked)
tried is as logged in..
no result..

Am I alone ?

Thanks for ANY news!

Regards
Helmut

[Piotr Gabryjeluk]

I can access the sites without any problem...

Dnia 2008-09-12, o godz. 08:19:59
Helmuti_pdorf <helmut.e...@kabsi.at> napisał(a):

--
Piotr Gabryjeluk
Wikidot.com developer

[Helmuti_pdorf]

That does not really help me now.... :)

I search now the firewall settings, the Service pack 3 ( WinXP) news,
the internet options for secure settings..

I set ALL off - and get no answer - only always the same empty screen
with a lot of text in the source code ( I can view it) , and a lot of
warnings in FF ( CSS not accepted like display, cursor, Xposition,
height ...)


Means - I get the page - but the browser is not showong me any content
and reads from Site and reads from wdfiles and read from siite an
reads from ....
and so on..

Could be - something with the theme on wdfiles.com ( or is it now n
static.wikidot.com ?) is no working as expected.

And another issue : my line is VERY slow now here where I am ( 56
kbit/sec)

I can get all publilc sites but no private one.

Wondering why, at home with a fast line and XP Sev pack 3 I had no
problems.

Any hint?

Regards
Helmut
- - - - -

Piotr Gabryjeluk wrote:
> I can access the sites without any problem...
>
> Dnia 2008-09-12, o godz. 08:19:59

[Piotr Gabryjeluk]

Hey,

this may be some sort of cache between you and Wikidot. To test if this
is the problem, try accessing the sites with https (proxies treat
differently http and https connections).

https://pro.wikidot.com/

Have luck!

Dnia 2008-09-12, o godz. 08:37:24
Helmuti_pdorf <helmut.e...@kabsi.at> napisał(a):

[Darren Pearce]

This is very curious. The other day, one of my colleagues was having what sounds like the exact same problem with our private site. The browser kept on going to host migen.wikidot.com then migen.wdfiles.com and back again. We thought it might be something to do with cookies somehow so deleted these. Now (apparently) they cannot log in at all it seems. I've yet to check this out though.

Given that this behaviour has happened to someone else now with wikidot, it sounds like a wikidot problem to me rather than a problem with my colleague's computer as I first thought.

Any clarification greatly appreciated. :-)

:Darren.

P.S. Helmut> you are not alone!

--
----------------------------------------------------------------------
:Darren :Pearce
----------------------------------------------------------------------
*** Shop & Donate: http://buy.at/campuskids ***
----------------------------------------------------------------------
dar...@dcs.bbk.ac.uk
Postdoctoral Researcher
London Knowledge Lab, University of London
----------------------------------------------------------------------
dar...@sussex.ac.uk
Visiting Research Fellow
Informatics, University of Sussex
http://www.informatics.sussex.ac.uk/users/darrenp/
----------------------------------------------------------------------
darren...@gmail.com
http://www.linkedin.com/in/darrenpearce
----------------------------------------------------------------------

[Piotr Gabryjeluk]

Hey,

this is a problem with some proxy/cache or something. We had precisely
analyzed the private wiki flow and this seems pretty OK. Even when
browser doesn't accept cookies, we can handle it and stop reloading
(and display cookie error).

The private wiki flow is as follows:

1. If user has rights to view the page, but has not cookie to view
wiki files, we redirect them to http://*.wdfiles.com/... to authenticate
them for wiki files.
2. wdfiles sets authenticating cookie and redirects to check the cookie
3. wdfiles checks if cookie is set. If not displays cookie error
If cookie is set and authorizes user to *.wdfiles.com, redirect them
back to the original URL
4. We're back at the original URL. The user can view content and
private files, so is not redirected anywhere.

This can only fail if some kind of proxy/cache remembers that original
URL is a redirect (as is in point 1) and sends the same response as in
point 1 even at the point 4.

To figure what exactly happens, we need some reports, including output
from tools like Firebug. Without it I really can't imagine situation
when something is wrong.

Thanks for understanding.

Dnia 2008-09-12, o godz. 16:40:49
"Darren Pearce" <darren...@gmail.com> napisał(a):

--
Piotr Gabryjeluk
Wikidot.com developer

[Брунхилда од Аустразије]

If it means something to you, I can open my private site without any problem....

2008/9/12 Helmuti_pdorf <helmut.e...@kabsi.at>

--
Brunehilda The Queen

[Helmuti_pdorf]

I think - the reason lies in the (big) "Service Pack 3" Update of
Microsofts Windows XP.....

since the restart after the update all is working in another way with
the internet.

in IE(7) as in FF(2)...

I doing some tests now

fact is - the login is working with private sites - coming back after
login test it is running in a circle...

now it has stopped at the ( very long!) url ( i Inserted spaces after
the http:):
@@http: / / admindevelopement.wikidot.com/local--auth/http%3A%2F
%2Fadmindevelopement.wikidot.com%2Fforum%3Arecent-posts@@

( Done in FF-status line).

I will try to uncheck at the login the box "bind my session to my
IP" ( or so)..

Thanks fpr your help!

Regards
Helmut

[Helmuti_pdorf]

The uncheck of the login box does not help!
would the CONTENT of the page I got ( empty screen, but lot of source
code) help ?

regards
Helmut
....

[Piotr Gabryjeluk]

Yes, please attach/paste it.

Dnia 2008-09-13, o godz. 00:39:29
Helmuti_pdorf <helmut.e...@kabsi.at> napisał(a):

[Piotr Gabryjeluk]

You could also try accessing some custom domain public wiki like
www.imatix.com , to see if similar circular-redirection problem appears
and whether you are logged in on this site. So:

1. Login to Wikidot.com
2. Go to www.imatix.com
3. Many redirects happen not pointing to anywhere -> BAD
4. Site loaded, but you are not logged in (login/create account links
appear) -> BAD
5. Site loaded, you see your icon and nickname at the top-right corner
-> GOOD

I ask for that, because we use similar mechanisms of cookie settings on
private wikis (for the wdfiles domain) and on custom domains.

Thanks in advance

Dnia 2008-09-13, o godz. 00:39:29
Helmuti_pdorf <helmut.e...@kabsi.at> napisał(a):

>
>

[Helmut Eichberger]

"Good news":
I have no problem at my home PC ( with router!) to come on my private sites
without any changes in the settings.
And I have no problems with your try on imATIX.com

2. bad news: on my laptop ( on the router with fast line) i got the FIRST
TIME (!) the message "error - please enable cookies for this domain..( or
so- I have managed to enable the cookies now for wdfiles.com..)

Reason for the bad situation I had :
I had written wrong the "wdfiles.com" domain - therefore this was blocked
instead of enabled!

And I got NEVer THIS MESSAGE ! - Could be on a very, very slow line ( 26
Kbit/sec) this message was never shown or up coming, because the circuing is
too long ?

Many thanks for your patient!

Helmut

-----Ursprüngliche Nachricht-----
Von: wik...@googlegroups.com [mailto:wik...@googlegroups.com] Im Auftrag
von Piotr Gabryjeluk
Gesendet: Samstag, 13. September 2008 11:19
An: wik...@googlegroups.com
Betreff: Re: Private Sites not reachable now -

You could also try accessing some custom domain public wiki like
www.imatix.com , to see if similar circular-redirection problem appears and
whether you are logged in on this site. So:

1. Login to Wikidot.com
2. Go to www.imatix.com
3. Many redirects happen not pointing to anywhere -> BAD 4. Site loaded, but
you are not logged in (login/create account links
appear) -> BAD
5. Site loaded, you see your icon and nickname at the top-right corner
-> GOOD

I ask for that, because we use similar mechanisms of cookie settings on
private wikis (for the wdfiles domain) and on custom domains.

Thanks in advance

Dnia 2008-09-13, o godz. 00:39:29

Helmuti_pdorf <helmut.e...@kabsi.at> napisal(a):

[Piotr Gabryjeluk]

So, it seems to be completely cookies problem, and not XP upgrade one?

Dnia 2008-09-14, o godz. 10:54:51
"Helmut Eichberger" <helmut.e...@kabsi.at> napisał(a):

[Helmut Eichberger]

I believe , it comes with the upgrade of Win XP - (service pack 3 )
creating new "standards" ( means default setings) for Internet setup.
("medium to high" for internet zone and not third party cookies allowed and
my "custom" set up was gone: always allowed for wikidot.com and
wdfiles.com ...)

I believe - with the newstart all was overwritten and I had to setup again
and allow the cookies for special domains.
But I never got the error message to have a look on the cookies setup.

After the correct allowence this is now happening as awaited before.

But I will test this again with my mobile - connection card ( and very slow
line perhaps, but this is difficult here at home).

Could be this was more an "internal" proxy server problem with the data
card and the slow line and not the missing cookies alone?
Fact is : I got the specific error at home only with the usage of the
high speed cabel-line.

Hope this helps a little.
Regards

Helmut

-----Ursprüngliche Nachricht-----
Von: wik...@googlegroups.com [mailto:wik...@googlegroups.com] Im Auftrag
von Piotr Gabryjeluk

Gesendet: Sonntag, 14. September 2008 11:13

An: wik...@googlegroups.com
Betreff: Re: Private Sites not reachable now -

So, it seems to be completely cookies problem, and not XP upgrade one?

Dnia 2008-09-14, o godz. 10:54:51

"Helmut Eichberger" <helmut.e...@kabsi.at> napisal(a):

[Darren Pearce]

Hi,

Many thanks for your response to my query and apologies for not replying sooner. Some of my colleagues are still experiencing this problem. I don't have detailed reports but I did just find out that the problem exists for one of my colleagues in Firefox on his machine but not using Safari. It seems the explanation you gave for thsi behaviour makes a lot of sense in that, somehow, Firefox specifically is caching the redirect. My colleague is working on a mac. Is there any way to clear this cache that you know of?

I am also curious as to why this problem exists for wikidot in the way that the login is processed but for no other site that my colleagues use.

Any further clarification much appreciated,

:Darren.