So you want to make a SAFE Website

#21

Note also that all other kinds of links I mentioned earlier also work:

But a problem is that a cross site unversioned link also works, though it shouldn’t have in order to follow perpetual web requirements.

For example with the following index.html file in files container pointed to by safe://test2 NRS map:

<!DOCTYPE html>
<html lang="en">
<head>
    ...
</head>
<body>
    <h1>My simple safe site</h1>
    <h2>Relative link</h2>
    <img src="img/safe_logo_blue.svg">
    <h2>Absolute link</h2>
    <img src="/img/safe_logo_blue.svg">
    <h2>Versioned safe link</h2>
    <img src="safe://test/img/safe_logo_blue.svg?v=1">
    <h2>Unversioned safe link</h2>
    <img src="safe://test/img/safe_logo_blue.svg">
</body>
</html>

The 4 images are displayed correctly. This is OK for the first 3 links, but the last one shouldn’t have been displayed because this version of safe://test2 will appear differently by issuing a new version of safe://test with a new safe_logo_blue.svg image.

Of course, a web site is allowed to evolve but the problem here is that it is modified without changing its version (I mean version of safe://test2 NRS map).

6 Likes
#22

Aha. Yeh. You’re right. We’ve a fix in place for this for resources from the same domain ( ie. Unspecified version of IMG/whatever.jpg will now resolve to the current version of the NRS map).

What you’re describing (as I understand) is that we should be blocking resources X domain wise, when no version is specified.

This should be pretty easy to get in atop the other fix. Though I wonder what the http response for this should be (as we need to be sending http in the end.) Perhaps just 403 forbidden for now. And the browser can log xdomain unspecified version or some such…

4 Likes
#23

You could instead just ignore the element and display a placeholder image, like when local links were not implemented:

3 Likes
#24

Results of safe files put -r ~/xtest and safe files put -r ~/xtest/ commands are not the same.

IMO, the presence or absence of a trailing slash on the directory name shouldn’t change the result. So, I opened an issue about this problem 20 days ago but didn’t receive any news about it. I would be glad if someone from @maidsafe could comment on this.

2 Likes
#25

Fyi: that difference in behavior also exists for the Linux command rsync (with a recursive flag). That rsync behavior was confusing for me at first, but now I’m used to it.

6 Likes
#26

Thanks @draw, I didn’t know rsync command behaves like this.

I agree that consistency with this command is a very good reason to have implemented safe files put command like they did:

  • Without a trailing /: the last element of source path is root of destination path
  • With a trailing /: the last element of source path is omitted in destination path
$ rsync -r remote:xtest .
$ tree .
.
└── xtest
   ├── img
   │   └── safe_logo_blue.svg
   └── index.html

2 directories, 2 files
$ rm -rf xtest
$ rsync -r remote:xtest/ .
$ tree .
.
├── img
│   └── safe_logo_blue.svg
└── index.html

1 directory, 2 files

I will close my issue with this remark.

7 Likes
#27

I think both approaches have their (dis)advantages. Lower priority atm for Maidsafe I guess

3 Likes
#28

Ok, for now I won’t close the issue and I will wait for comments from Maidsafe.

5 Likes
#29

They have already answered somewhere that this was done for consistency with rsync.

4 Likes
#30

rsync is a very common UNIX/Linux tool. Hell, it can even be made to work on Windows, so I am led to believe… If Maidsafe were to step away from consistency with the industry standards, at least in terms of common practice and usability, I for one would be very annoyed - and quite surprised.

5 Likes