delete integrated-browser history?

ID:138231
 
Jan 10 2001, 8:23 pm
I was just wondering if it were possible, either in JavaScript or in DM itself, to delete the DS' browser's history list, so I can prevent players from ever seeing stuff that is no longer valid. On the internet you can make a page expire, but that wouldn't apply to this if it has to directly communicate with BYOND.

Any takers?
Jan 10 2001, 9:19 pm
On 1/10/01 11:23 pm Spuzzum wrote:
I was just wondering if it were possible, either in JavaScript or in DM itself, to delete the DS' browser's history list, so I can prevent players from ever seeing stuff that is no longer valid. On the internet you can make a page expire, but that wouldn't apply to this if it has to directly communicate with BYOND.

Any takers?

Well, I've asked away in ZDNet's ScriptHead forum. I'll see if I get a response there.

Currently, I know that all of the history items are handled by the history object, but I'm not sure if I could use

delete history.current

to remove the current entry from the history. It'd be nice if I could delete the entire list, but that won't happen, and it could be used maliciously anyway (imagine getting redirected to an inappropriate site, then being inable to return... grr on the redirection, and grr on the inability to return.).

I also noticed* the method location.replace(), but I don't think BYOND would be able to communicate with it if I were to use

javascript:location.replace("byond://#test/test")

It rather stinks that we don't have any JavaScript experts here! =P


<small>* Why do people spell it "knowticed"...? The word is derived from "note", not "know". That just drives me plain insane.</small>
Jan 11 2001, 12:38 pm
On 1/10/01 11:23 pm Spuzzum wrote:
I was just wondering if it were possible, either in JavaScript or in DM itself, to delete the DS' browser's history list, so I can prevent players from ever seeing stuff that is no longer valid. On the internet you can make a page expire, but that wouldn't apply to this if it has to directly communicate with BYOND.

Any takers?

I don't know how to do this, but I think we may be able to accomodate your ultimate goal, that is, inferring from a previous post, the ability to prevent users from backtracking onto previously generated pages.

I am thinking that pages output by browse() or file() should not be cached at all (and thus not be navigatable by either the arrows or the http:// protocol). Would there be any objections if I simply applied this rule throughout?

I'm also thinking that blocking byond:// style links from http:// navigated pages might be the way to go. In other words, only pages output to browse() or text() could use byond:// links; a user couldn't go to a page with byond:// links simply by navigating to it. I am thinking that no one uses regular http:// pages that contain embedded byond:// links (since they couldn't display in a normal web browser anyway), but I could be wrong. What do y'all think?
Jan 11 2001, 1:16 pm
In response to Tom H.
On 1/11/01 3:38 pm Tom H. wrote:
I am thinking that no one uses regular http:// pages that contain embedded byond:// links (since they couldn't display in a normal web browser anyway), but I could be wrong. What do y'all think?

Not a reliable assumption...one of my potential ways of popping up pages in DragonSnot is to point the player to a page from the webserver.

I haven't actually done that at this point, and probably wouldn't given that the server approach is so easy, but I can see people doing it.

The reason: If you distribute a hubbified game, it's still in your interest to keep as much as you can out of the client so you can update the game in various ways without making players download it again.

Having some pages which are appropriate to leave on the net (related to uploading/downloading and the like) allows you to make changes to those pages without updating the client. And maintaining them as simple HTML pages in the web directory is the simplest way to implement them.
Jan 11 2001, 5:26 pm
In response to Tom H.
On 1/11/01 3:38 pm Tom H. wrote:
I am thinking that pages output by browse() or file()
should not be cached at all (and thus not be navigatable
by either the arrows or the http:// protocol). Would
there be any objections if I simply applied this rule
throughout?

I'm also thinking that blocking byond:// style links from
http:// navigated pages might be the way to go. In other
words, only pages output to browse() or text() could use
byond:// links; a user couldn't go to a page with
byond:// links simply by navigating to it. I am thinking
that no one uses regular http:// pages that contain
embedded byond:// links (since they couldn't display in a
normal web browser anyway), but I could be wrong. What do
y'all think?

Related to what Deadron was writing, my help file system pretty much is a mixture of standard html and byond. I like having the files outside of byond so that I can edit them easily without having to recompile the code, but they still need to link into the code for various functions.

Security wise, as a MUD based system it is imperative that what is actually cached by the client is not going to be something that can be used against the system or cause problems in other ways. The help system isn't really a security risk though, at least so far it isn't...

Jan 11 2001, 7:04 pm
In response to Gabriel
On 1/11/01 8:26 pm Gabriel wrote:

Related to what Deadron was writing, my help file system pretty much is a mixture of standard html and byond. I like having the files outside of byond so that I can edit them easily without having to recompile the code, but they still need to link into the code for various functions.

Fair enough. Allowing byond:// access from http:// pages does introduce a bit of a security hole in your games, but with some work you should be able to control it. We may be able to introduce some provisions in the future to aid in this process. Even if we were to have the aforementioned restriction, users could still get around the security by outputting their own byond:// links through text, for instance.

For non-distributed games, I suggest that you still use the pure byond:// protocol for making dynamic pages. For example:

mob/verb/help() // view the help "page"
usr << browse(file("help.html"))

And then you can edit the file, "help.html", that resides on the server. This is just as dynamic as if it were a web page, but does not require any webspace (or the security loopholes that come with it). If you are distributing your game there is no fixed server, so this approach won't work. Kudos to Deadron for pointing this out.
Jan 12 2001, 6:27 pm
In response to Tom H.
On 1/11/01 3:38 pm Tom H. wrote:
I am thinking that pages output by browse() or file() should not be cached at all (and thus not be navigatable by either the arrows or the http:// protocol). Would there be any objections if I simply applied this rule throughout?

Oh no!

The ability to navigate back through browse()d pages is part of what allows me to do my GM changes to things in Cerulea with any speed at all. That night I was changing everyone's titles around (Slave Tom and all that), I had everyone's stat page cached and was just navigating around, which is much faster (on my computer, anyway) than loading up a new one each time.

But I think the ability to keep people from going back to old forms is very important too. Is it possible to include another argument in browse() to keep pages from being cached (or make sure they are)?

Z
Jan 12 2001, 7:11 pm
In response to Zilal
On 1/12/01 9:27 pm Zilal wrote:
On 1/11/01 3:38 pm Tom H. wrote:
I am thinking that pages output by browse() or file() should not be cached at all (and thus not be navigatable by either the arrows or the http:// protocol). Would there be any objections if I simply applied this rule throughout?

Oh no!

Not to fear. We won't make any changes to the current system until we can come up with a consensus that satisfies everyone. It will probably be some sort of cache argument, as you suggested.