search

linkeddata / dokieli

:bulb: dokieli is a clientside editor for decentralised article publishing, annotations and social interactions
https://dokie.li/
Other
803 stars 82 forks source link

Create a document in dokieli misses the .html extension #270

Closed bourgeoa closed 5 years ago

bourgeoa commented 5 years ago

When you create a new document from inside dokieli you create a file with no .html and it is not usable.

csarven commented 5 years ago

What is not usable exactly? I think the issue you're experiencing has to do with the server not serving the resource that you've saved properly. It is just an HTML document after all. Can you show or see that the request; HTTP headers and the payload that is being sent to the server as malformed? If so, then that'd be an issue in dokieli.

bourgeoa commented 5 years ago

Sorry for no follow up, the problem arise when you don't type a document name, then the document is created with a random file name with no extension.

csarven commented 5 years ago

I don't understand the problem about why or how having different URL names is not usable in dokieli. Why shouldn't dokieli request a name if the user doesn't provide one? The server ultimately picks the name any way.

bourgeoa commented 5 years ago

You are right information is not lost, the user is lost and try to understand where are his data. It is not a bug per se, it is not user friendly with his errors.

csarven commented 5 years ago
bourgeoa commented 5 years ago

I join an image, that should answer to the situation :

hope it helps screenshot_2019-02-10-14-48-48-868_com android chrome

bourgeoa commented 5 years ago

It is also not clear that you have to choose Open ID connect to sign in. WebId works but you cannot connect with password, so it works only for folders/files with read/write for everybody

csarven commented 5 years ago

A URL including a UUID is proposed by dokieli within the container/storage location that's detected or in use. That doesn't prevent the user from specifying the location to save to. So, I still don't understand the issue here. Is there anything failing? What was your expectation (and why) and what happened instead? What dokieli presents as the destination URL is only a proposal. It changes every time the parent container location is changed. In any case, the user can always enter the name themselves in the input field.

As for //, that's a bug in solid server v4, but may be fixed in v5.

csarven commented 5 years ago

https://github.com/linkeddata/dokieli/issues/270#issuecomment-462136049 is unrelated to this issue. I think what you're raising is described in https://github.com/linkeddata/dokieli/issues/274#issuecomment-449151394 .

The WebID input field is used for non-auth as well WebID-TLS based auth, an that uses browser certificates, so you shouldn't be seeing password fields on a webpage or something. The OpenID sign in uses WebID-OIDC based auth, which may require a password to sign-in through the identity provider. I hope that clarifies.

bourgeoa commented 5 years ago

My expectation was to have no random file proposal

As for the webId field or OpenID I suppose that it is because I came to all of this with no other background than Solid server. I use more than one webId and the browser certificates are then frequently not the good ones and I am returned 401. This point as I understand as nothing to do with dokieli. Just frustrating.

csarven commented 5 years ago

Whether the user gives a name or dokieli proposes on, the server still decides in the end. The point for dokieli to come up with one was to simplify the process - less clicks for instance. When you do a "Save Page As" for example in your Web browser, it reuses the title of the URL as the filename - unless the user inputs their own. So, I don't think dokieli's approach is foreign, if anything, inline with existing practice. But, I understand that it can be argued otherwise. Just not sure if the counter is as strong.

.html string is not required to be part of the URL. Why would omitting that be invalid? Can you point to a specification that makes that case?

I hear your frustration with authentication, but it is ultimately out of dokieli's scope. dokieli will reuse/implement existing mechanisms, and strive to make the UI work well.

bourgeoa commented 5 years ago

As for .html I understood but maybe wrong that as from NSS v5 default file with no extension are not anymore turtle file and at the same time that file with no extension will be deemed binary files. I don't remember the exact term. It may only concern Solid UI. Sorry for my bad explanations I am by no way a professional either by background or practice.

csarven commented 5 years ago

The behaviour that you're describing with no-extension and getting treated as Turtle is something that NSS v4 does. NSS v5 will actually internally handle the extension when it writes to its disk. So, if dokieli gives /foo, it will be saved as /foo$.html, however, the URL will only be known as /foo. In any case, that is an implementation decision that Solid makes. What dokieli cares about is whether a server allows it to create/read resources. URL naming is not supposed to influence the interaction.

Thanks a lot for taking the time to give your feedback! I wanted to make sure that we didn't misunderstand each other.

If you're satisfied with the feedback, feel free to close this issue.