in reply to Re: A new chatterbox flavour
in thread A new chatterbox flavour

Logging in cloaked was by design, but I suppose it's counterproductive for people who just want to use the client, rather than hack on it. Since so many people complained about that I've commented out the parameter which tells PM to cloak the login, so download the code again and you should be good to go.

I cannot use an existing PM cookie; it is a security feature of JS to prevent you from reading the cookies set by other sites. The plan was and is to eventually have a copy of this hosted on PM, so a separate login won't be necessary. I just need the tuits to implement the bits that will be difficult to do in JS (interpret markup) and those I don't have any personal need for (private messages).

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^3: A new chatterbox flavour
by bart (Canon) on Jan 14, 2005 at 07:38 UTC
    So if you can't read the cookie, perhaps there's a simple way to ask the site who you are? Maybe by parsing the Login Page, it has a fixed format and contains your user name — take the print version, and what you're after is in the first link in the DIV with the id "content".Or maybe there's even a ticker that's even better suited.

    I like the idea of combining a cloaked chatterbox while browsing the site logged in normally. If your browsing and the chatterbox are on the same domain, you can't have that. Not like this.

    Is there something we're overlooking? Some parameter for the request which would make this single request cloaked, leaving the cookie intact?

[reply]

      I like the idea of combining a cloaked chatterbox while browsing the site logged in normally.

      Well, what is the purpose?

      In any case, the login stuff was cruft added for the interim. I don't plan on adding even more cruft to better support a scenario that's only temporary…

      Makeshifts last the longest.

[reply]
        Well, what is the purpose?

        If you take a look to Other Users, at any point in time there will be at least a few people that show up, but who aren't actually present, they just left Fullpage Chat or some other chatterbox client open. Such an automatic check of messages, either personal or chatter, should not register as presence, IMHO.

        I don't plan on adding even more cruft to better support a scenario that's only temporary…

        I can have no argument whatsoever with that.

        It is not fair that a shortcoming in the site should be patched in a chat client, in every chat client. It is the responsibility of the site to treat these things properly, whatever anybody deems proper.

        IIRC cookie processing, and thus marking the presence of a user, happens at a very early stage, before any custom node code can have a say in it. That way, a patch would have to dig very deeply into the guts of the site. I have serious doubts whether the people responsible for the state of the site would be so happy to have that happen.

[reply]

In Section Perl Monks Discussion