Re: Attempt to de-mystify AJAX

[CHOP]

> On my application I (the designer, that is) am in control, and I simply
> don't allow hyperlinks that can overlay the page. I know that can be a
> major problem. "Hyperlinks" always open a new browser window. In our
> world, there's absolutely no problem with that. Does this issue go away
> then? Is this is an issue with Flashconnect? Or else I still don't get it.
>

Hyperlinks don't open new browser windows. Hyperlinks are uniform resource
locators (URLs) that the browser uses to move to another location, without
requiring the user to manually specify the location each time. Your browser
opens a new window when clicking hyperlinks because you have specified that
it should behave that way. You can configure that by browser, desktop, and
user of the O/S.

>
> Yes, you are making a statement about "typical" Web app design. No
> argument there. But I am talking about a solution to the disconnection
> problem. It's as equally valid in my world as it would be in the "typical"
> Web application. Just because they choose not to use it or don't need it
> does not mean it is inapplicable.
>
> And I realize I am misusing the term "keep-alive". Maybe "I-am-alive
> signal" What I meant is that the server, from its state tables, can easily
> determine whether the connection is valid or not, not the other way
> around, because it expects a repetitive signal from the browser. So the
> server simply cleans up locks and any other detritus when the browser is
> not longer alive.
>

There's the biggest architectural difference in our discussion. You are
performing a peudo-persistant application, while I am not. I merely require
an identification tag from the browser. I don't care how it gets to me(the
server) or how often I get it, as long as it stays consistent with the
browser+connection. For example, our shopping cart cookies are valid for 24
hours. If you shop our site today and come back 12 hours later, your cart
contents will still be stored and waiting for you - as long as the session
key (cookie) is still there and still contains the original value. After 24
hours, a background process wipes all traces of the session from the temp
files and the cookie will automatically expire inside the browser. The best
part is that I don't have to refresh anything. I only need to make sure it's
there. If it's not a new one is generated and then stored. Unfortunately,
even that "nice-ity" is biting me in the rear. Security settings and cookie
handling discrepencies are still causing state problems for some shoppers.
It looks like I will be forcing all of our content to be run through the MV
web engine in order to pass around the session key using the most basic
methods. Back to square one, after 5/6 years of development. :(

You can use PHP with CGI calls (FC, Red Back, whatever) and DHTML to
potentially achieve much more robustness over JS packet bouncing. I'd need
to understand your framework a lot more, but if you're interested drop me an
e-mail.

>>>> I know that from previous and current experience. I am trying to
>>>> working around cookies and JS, but it seems to be tough. Hidden frames
>>>> allow you to separate the persistant and non-persistant content, but
>>>> send them both as needed back to the server. The problem that I have
>>>> with that is the fact that a frame has its own DOM and can not be
>>>> addressed as part of the overall document in focus. I don't like having
>>>> multiple document objects to deal with.Using cookies eliminates the
>>>> need to pass stuff back and forth manually, or through the use of
>>>> potentially flakey scripting
>>> Addressing your data structures has nothing to do with whether or not
>>> you can maintain persistence. Personally I think it's a lot easier
>>> referencing an element I set up as a hidden input field than segments of
>>> a cookie.
>>> I don't do flaky scripting, or more correctly, scripting to get cookie
>>> parts may be just as flaky as any other scripting. Has no relevance to
>>> the issues. Also, how can you "work[ing] around cookies and JS" when you
>>> need JS to access the cookie?
>>
>> Umm... cookies are raw HTTP headers, available via CGI environment
>> variables, and have absolutely nothing to do with JS, PHP, or any other
>> client or server 3rd party technology. I don't know what you are talking
>> about! Trust me, I know the ins and outs of HTTP services. :P
>
> Again, I probably don't know enough about the multitudinous ways you can
> reference data. In my book, I'd use :
> var fields = unescape(document.cookie).split(...) or something, which,
> last I looked, is javascript. What can you do on clientside with cookies
> that does not involve javascript or another language (sincerely)?

JS: access the cookies through the DOM as an object.
CGI: You can get the cookies from the HTTP_COOKIE CGI environment variable.
Just like you use QUERY_STRING or REMOTE_ADDR.
Perl: Direct access via the environment functions or you can plug in a
number of HTTP modules that simplify header reading.
C: If you are running the C app under the CGI environment, then you can pull
the environment variable as a normal shell environment variable.

Give me a language and I'll tell you how to get and set a cookie.

>
> On reading this carefully, it seems we are in *total agreement*-we need a
> immutable session key?
>
> Chandru Murthi
>

Yup. The trick is being able to quietly pass the key from click to click,
without worrying that it's going to disappear somehow. In your case, that's
not a problem because your environment is completely server driven. Mine
isn't; however. Most web development is not 100% database driven. It's a mix
of technology.

Glen



--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
.

Relevant Pages

  • Re: How to save onclick event in cookie?
    ... Will this be saved even if I close the browser and restart it at a later ... > Marco Krechting wrote: ... >> I have a page with a list of hyperlinks. ... >> I want to save information in a cookie about the fact that I entered an ...
    (comp.lang.javascript)
  • Re: NSA Used Cookies to Track Visitors Web Activities?
    ... Could unwittingly installing a compromised browser open the doors wide to cookie-based intrusions? ... A cookie itself is unlikely to be a virus, but if the browser code is written in C, it is very likely to have arrays that are susceptible to "buffer overrun" Sometimes a clever enough person can use such a bug to cause executable code stored in an allegedly non-executable file to replace code in your browser or operating system. ... an external intruder coming in over an Internet connection, presumably that intruder would have access to the cookies on one's machine. ...
    (comp.sys.mac.system)
  • Re: Cookies from ASP.NET app not persisting even when enabled!
    ... > I'm new to ASP.NET and have been developing a small app at work to test ... > and the authorization cookie is saved as expected on the local machine. ... any browser OTHER THAN the one on the development ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Great SWT Program
    ... Every browser I've ever ... server when requesting any URLs from that server. ... doesn't send the cookie. ... every so often nail the ones that got by adblock, ...
    (comp.lang.java.programmer)
  • RE: A technique to mitigate cookie-stealing XSS attacks
    ... Everyone interested in preventing XSS should review and understand ... remote procedure call instruction encoding where the browser or its OS ... browsers SHOULD adopt support for "client-side ... This new HTTPOnly security feature would simply stop cookie hijacking ...
    (Bugtraq)