I am trying to implement a simple authentication for my Gemini site, and was planning to use a client certificate CN field to pass username:password pair to server. However, upon reading closely about the TLS handshake - https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake - it seems that the client (just like the server) certificate is sent before the ChangeCipherSpec record, i.e. insecure. That means to me that the CN field would be passed before the TLS session is started and therefore not suitable as an authentication medium. Is that correct? Another alternative to implement username/password type authentication in Gemini would be the sensitive input status code, but then I would have to store a list of certificate fingerprint and username pairs, greatly complicating the system. Given that Gemini protocol strives to be minimal/low-cost for both users and client/server devs, has anyone found a simple way to implement username/password type authentication systems? To be fair, I have attempted to use client short-/long-lived client certificates as per recommendation in Gemini protocol specification; however, if access to the same "account" from multiple devices and being able to survive certificate loss without permanently losing access is my account are requirements, this authentication method quickly becomes a mess. For example, think about how one would go about getting access to their astrobotany plant on a new device. This is why I ended up going back to username/password authentication, but having difficulties making sure that everything is secure. In need of help/suggestions/ideas, thanks.
On Sun, 2020-07-19 at 21:26 +0200, Peter Vernigorov wrote: > I am trying to implement a simple authentication for my Gemini site, > and was planning to use a client certificate CN field to pass > username:password pair to server. However, upon reading closely about > the TLS handshake - > https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake > - > it seems that the client (just like the server) certificate is sent > before the ChangeCipherSpec record, i.e. insecure. That means to me > that the CN field would be passed before the TLS session is started > and therefore not suitable as an authentication medium. Is that > correct? Well, my experience is that you tell the server that you want to verify peer certificates (which is typically off for servers); then the client sends you a server that won't validate if you do nothing else: you have to overwrite the default validation code and return True for everything. Then your code gets the client certificate and now you can do the real validation in your app instead of on the TLS layer. Here's a long blog post: https://alexschroeder.ch/wiki/2020-07-13_Client_Certificates_and_IO%3a%3aSo cket%3a%3aSSL_(Perl) Here's where I tell my server that I want to verify peers (client certificates) and that I will provide my own verification code: https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n758 Here's the verification code for the TLS library which accepts anything: https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n775 Here's some example code that does actual validation, requests a client certificate if none is available, etc: https://alexschroeder.ch/cgit/gemini-wiki/about/#client-certificates Good luck! And yes, I'm using more traditional access tokens for my wiki per default. ?
Thanks for the reply Alex. My understanding is that your blog post
talks about how to get the server to request that the client sends the
certificate, and you are right that many Gemini servers don?t usually
do that. When writing Gig framework - https://github.com/pitr/gig -
and having the same issue, I noticed that most Go-based Gemini servers
out there don?t do this but a quick search showed that it?s just a
matter of one line change to get it working properly:
&tls.Config{
MinVersion: tls.VersionTLS12,
ClientAuth: tls.RequestClientCert // <-- this line, default is NoClientCert
}
Anyhow, when the client DOES send the certificate, it seems to do it
in plain text. See this excerpt from TLS handshaking:
...
- The server sends its ServerKeyExchange message (depending on the
selected cipher suite, this may be omitted by the server).
...
- The client responds with a Certificate message, which contains the
client's certificate.
...
- The client now sends a ChangeCipherSpec record, essentially telling
the server, "Everything I tell you from now on will be authenticated
(and encrypted if encryption was negotiated)."
...
Notice how the certificate is sent before client starts encrypting
messages. This means that the CN (and other) fields are also in plain
view and therefore cannot contain secret information.
On Sun, Jul 19, 2020 at 10:03 PM Alex Schroeder <alex at gnu.org> wrote:
>
> On Sun, 2020-07-19 at 21:26 +0200, Peter Vernigorov wrote:
> > I am trying to implement a simple authentication for my Gemini site,
> > and was planning to use a client certificate CN field to pass
> > username:password pair to server. However, upon reading closely about
> > the TLS handshake -
> > https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake
> > -
> > it seems that the client (just like the server) certificate is sent
> > before the ChangeCipherSpec record, i.e. insecure. That means to me
> > that the CN field would be passed before the TLS session is started
> > and therefore not suitable as an authentication medium. Is that
> > correct?
>
> Well, my experience is that you tell the server that you want to verify
> peer certificates (which is typically off for servers); then the client
> sends you a server that won't validate if you do nothing else: you have
> to overwrite the default validation code and return True for
> everything. Then your code gets the client certificate and now you can
> do the real validation in your app instead of on the TLS layer.
>
> Here's a long blog post:
> https://alexschroeder.ch/wiki/2020-07-13_Client_Certificates_and_IO%3a%3a
Socket%3a%3aSSL_(Perl)
>
> Here's where I tell my server that I want to verify peers (client
> certificates) and that I will provide my own verification code:
> https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n758
>
> Here's the verification code for the TLS library which accepts
> anything:
> https://alexschroeder.ch/cgit/gemini-wiki/tree/gemini-wiki#n775
>
> Here's some example code that does actual validation, requests a client
> certificate if none is available, etc:
> https://alexschroeder.ch/cgit/gemini-wiki/about/#client-certificates
>
> Good luck!
>
> And yes, I'm using more traditional access tokens for my wiki per
> default.
>
I see this as the same issue that exists for clients - without a trusted
CA, there's nothing to stop me masquerading as anyone else, other than the
certificate (e.g. fingerprint) pinning, so I believe the process absolutely
needs a (one-time) login prompt to pin the certificate - I can't see a way
to avoid it.
Your question made me think about what would be the minimum steps required
to implement client TOFU with PIN or password verification, and the code
below is my take on what I think has to happen. Note the code is only meant
as a concise way to discuss the process.
So, for example, a request to a private resource, such as: -
gemini://susa.net/cgi-bin/private.sh?articleId=1234
Might be handled something like this: -
$ cat private.sh
#!/bin/bash
# If we have no client certificate, request one.
if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
elif [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) == "" ]]; then
# We've never seen this user's client hash, so challenge for a PIN
# (we could store this current URL for onward forwarding)
echo -ne "30 /cgi-bin/login.sh\r\n"
else
echo -ne "20 text/gemini\r\n"
echo "This is the prize inside the protected resource!"
fi
I think a redirect to a login process is unavoidable, because any
originating request might have its own query_string, yet we're going to
need one for the password prompt response. So the login.sh would be our
one-time verification to pin the certificate to a CN based user-id.
$ cat login
#!/bin/bash
# If we have no client certificate, request one.
if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
exit
fi
# If the certificate has no CN, then reject it
if [[ "${REMOTE_USER}" == "" ]]; then
echo -ne "20 text/gemini\r\n"
echo "Your CN can't be used as a user-id!"
exit
fi
# We have a client certificate, is it already authorised?
if [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) != "" ]]; then
echo -ne "20 text/gemini\r\n"
echo "You are already authorised!"
exit
fi
# We have a certificate and a valid user-id (CN), so either prompt for
# a PIN, or verify PIN if we've been given a QUERY_STRING.
# Grep the remote user's line from the passwd file (format CN:PIN)
PWD_ENTRY=$(grep "^${REMOTE_USER}:" login_passwd)
# Strip the CN value and separator, leaving the PIN
MY_PIN="${PWD_ENTRY#${REMOTE_USER}:}"
# Check for our PIN in the query string (which may be empty)
if [[ "${QUERY_STRING}" == "${MY_PIN}" ]]; then
echo -ne "20 text/gemini\r\n"
echo "Your PIN checks out, ${REMOTE_USER}!"
echo "${TLS_CLIENT_HASH}" >>/tmp/${REMOTE_USER}_sigs
echo "Your hash has been stored in '/tmp/${REMOTE_USER}_sigs'"
exit
fi
echo -ne "11 Please enter your PIN, ${REMOTE_USER}\r\n"
On Sun, 19 Jul 2020 at 20:26, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> I am trying to implement a simple authentication for my Gemini site,
> and was planning to use a client certificate CN field to pass
> username:password pair to server. However, upon reading closely about
> the TLS handshake -
> https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake -
> it seems that the client (just like the server) certificate is sent
> before the ChangeCipherSpec record, i.e. insecure. That means to me
> that the CN field would be passed before the TLS session is started
> and therefore not suitable as an authentication medium. Is that
> correct?
>
> Another alternative to implement username/password type authentication
> in Gemini would be the sensitive input status code, but then I would
> have to store a list of certificate fingerprint and username pairs,
> greatly complicating the system.
>
> Given that Gemini protocol strives to be minimal/low-cost for both
> users and client/server devs, has anyone found a simple way to
> implement username/password type authentication systems? To be fair, I
> have attempted to use client short-/long-lived client certificates as
> per recommendation in Gemini protocol specification; however, if
> access to the same "account" from multiple devices and being able to
> survive certificate loss without permanently losing access is my
> account are requirements, this authentication method quickly becomes a
> mess. For example, think about how one would go about getting access
> to their astrobotany plant on a new device. This is why I ended up
> going back to username/password authentication, but having
> difficulties making sure that everything is secure. In need of
> help/suggestions/ideas, thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200720/8bb3
276f/attachment.htm>
Hey Kevin,
Yes this solution sounds good, pin is passed as part of query string.
Username is still visible outside tls session of course.
But I think the bigger problem is that now I need to store usernames, pins,
all of user?s cert fingerprints and their first seen and last seen dates, I
would need to build an interface to delete old/lost fingerprints, etc.
Compare that to basic auth in http, which while might not be pretty,
involves very little code to implement: check username/password hash
against ones in db on every request (in a before filter if framework
supports it) and I?m done.
By the way, your solution is very similar to how client ssh usually works,
one would login using username/password into a new server or from a new
client, and then add their client certificate to ~/.authorized_keys. So far
yours is the best solution, but I wonder if there?s a simpler, more elegant
way.
On Mon, Jul 20, 2020 at 16:50 Kevin Sangeelee <kevin at susa.net> wrote:
> I see this as the same issue that exists for clients - without a trusted
> CA, there's nothing to stop me masquerading as anyone else, other than the
> certificate (e.g. fingerprint) pinning, so I believe the process absolutely
> needs a (one-time) login prompt to pin the certificate - I can't see a way
> to avoid it.
>
> Your question made me think about what would be the minimum steps required
> to implement client TOFU with PIN or password verification, and the code
> below is my take on what I think has to happen. Note the code is only meant
> as a concise way to discuss the process.
>
> So, for example, a request to a private resource, such as: -
>
> gemini://susa.net/cgi-bin/private.sh?articleId=1234
>
> Might be handled something like this: -
>
> $ cat private.sh
> #!/bin/bash
>
> # If we have no client certificate, request one.
> if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
>
> echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
>
> elif [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) == "" ]];
> then
>
> # We've never seen this user's client hash, so challenge for a PIN
> # (we could store this current URL for onward forwarding)
> echo -ne "30 /cgi-bin/login.sh\r\n"
>
> else
>
> echo -ne "20 text/gemini\r\n"
> echo "This is the prize inside the protected resource!"
> fi
>
> I think a redirect to a login process is unavoidable, because any
> originating request might have its own query_string, yet we're going to
> need one for the password prompt response. So the login.sh would be our
> one-time verification to pin the certificate to a CN based user-id.
>
> $ cat login
> #!/bin/bash
>
> # If we have no client certificate, request one.
> if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
> echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
> exit
> fi
>
> # If the certificate has no CN, then reject it
> if [[ "${REMOTE_USER}" == "" ]]; then
> echo -ne "20 text/gemini\r\n"
> echo "Your CN can't be used as a user-id!"
> exit
> fi
>
> # We have a client certificate, is it already authorised?
> if [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) != "" ]]; then
> echo -ne "20 text/gemini\r\n"
> echo "You are already authorised!"
> exit
> fi
>
> # We have a certificate and a valid user-id (CN), so either prompt for
> # a PIN, or verify PIN if we've been given a QUERY_STRING.
>
> # Grep the remote user's line from the passwd file (format CN:PIN)
> PWD_ENTRY=$(grep "^${REMOTE_USER}:" login_passwd)
>
> # Strip the CN value and separator, leaving the PIN
> MY_PIN="${PWD_ENTRY#${REMOTE_USER}:}"
>
> # Check for our PIN in the query string (which may be empty)
> if [[ "${QUERY_STRING}" == "${MY_PIN}" ]]; then
> echo -ne "20 text/gemini\r\n"
> echo "Your PIN checks out, ${REMOTE_USER}!"
> echo "${TLS_CLIENT_HASH}" >>/tmp/${REMOTE_USER}_sigs
> echo "Your hash has been stored in '/tmp/${REMOTE_USER}_sigs'"
> exit
> fi
>
> echo -ne "11 Please enter your PIN, ${REMOTE_USER}\r\n"
>
>
> On Sun, 19 Jul 2020 at 20:26, Peter Vernigorov <pitr.vern at gmail.com>
> wrote:
>
>> I am trying to implement a simple authentication for my Gemini site,
>> and was planning to use a client certificate CN field to pass
>> username:password pair to server. However, upon reading closely about
>> the TLS handshake -
>> https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake -
>> it seems that the client (just like the server) certificate is sent
>> before the ChangeCipherSpec record, i.e. insecure. That means to me
>> that the CN field would be passed before the TLS session is started
>> and therefore not suitable as an authentication medium. Is that
>> correct?
>>
>> Another alternative to implement username/password type authentication
>> in Gemini would be the sensitive input status code, but then I would
>> have to store a list of certificate fingerprint and username pairs,
>> greatly complicating the system.
>>
>> Given that Gemini protocol strives to be minimal/low-cost for both
>> users and client/server devs, has anyone found a simple way to
>> implement username/password type authentication systems? To be fair, I
>> have attempted to use client short-/long-lived client certificates as
>> per recommendation in Gemini protocol specification; however, if
>> access to the same "account" from multiple devices and being able to
>> survive certificate loss without permanently losing access is my
>> account are requirements, this authentication method quickly becomes a
>> mess. For example, think about how one would go about getting access
>> to their astrobotany plant on a new device. This is why I ended up
>> going back to username/password authentication, but having
>> difficulties making sure that everything is secure. In need of
>> help/suggestions/ideas, thanks.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200720/5bda
12bc/attachment-0001.htm>
Hi Peter,
The only simplification that I had in mind was to disregard the CN entirely
and replace the PIN with a unique auth-token that they'd have to use to add
a new certificate to their profile.
The storage/processing is not much more complex than with
username/passwords - a profile is just a unique auth-token and a list of
hash strings. Realistically, there's no need to delete anything unless you
revoke their account (delete everything) or a certificate has expired
(remove its hash to force a re-auth).
You could have all auth requests go through a single CGI script, which
would allow you to separate authentication from the actual content. For
example, I have a CGI script called 'serverinfo', and when I make a request
to the script with extra path info, the script is invoked and the extra
path is made available to the script. e.g. gemini://
gemini.susa.net/cgi-bin/serverinfo/something/else.gmi yields variables: -
? GEMINI_URL: gemini://gemini.susa.net/cgi-bin/serverinfo/something/else.gmi
? SERVER_NAME: gemini.susa.net
? SERVER_PROTOCOL: GEMINI
? SERVER_SOFTWARE: gemserv
? SCRIPT_NAME: /cgi-bin/serverinfo
? QUERY_STRING:
? PATH_INFO: /something/else.gmi
The PATH_INFO could then be used by subsequent code to 'direct' the CGI
script to generate the correct content, meaning that all your 'handler'
code could assume that validation has passed, a little more like typical
HTTP based code.
Kevin
On Mon, 20 Jul 2020 at 22:27, Peter Vernigorov <pitr.vern at gmail.com> wrote:
> Hey Kevin,
>
> Yes this solution sounds good, pin is passed as part of query string.
> Username is still visible outside tls session of course.
>
> But I think the bigger problem is that now I need to store usernames,
> pins, all of user?s cert fingerprints and their first seen and last seen
> dates, I would need to build an interface to delete old/lost fingerprints,
> etc. Compare that to basic auth in http, which while might not be pretty,
> involves very little code to implement: check username/password hash
> against ones in db on every request (in a before filter if framework
> supports it) and I?m done.
>
> By the way, your solution is very similar to how client ssh usually works,
> one would login using username/password into a new server or from a new
> client, and then add their client certificate to ~/.authorized_keys. So far
> yours is the best solution, but I wonder if there?s a simpler, more elegant
> way.
>
> On Mon, Jul 20, 2020 at 16:50 Kevin Sangeelee <kevin at susa.net> wrote:
>
>> I see this as the same issue that exists for clients - without a trusted
>> CA, there's nothing to stop me masquerading as anyone else, other than the
>> certificate (e.g. fingerprint) pinning, so I believe the process absolutely
>> needs a (one-time) login prompt to pin the certificate - I can't see a way
>> to avoid it.
>>
>> Your question made me think about what would be the minimum steps
>> required to implement client TOFU with PIN or password verification, and
>> the code below is my take on what I think has to happen. Note the code is
>> only meant as a concise way to discuss the process.
>>
>> So, for example, a request to a private resource, such as: -
>>
>> gemini://susa.net/cgi-bin/private.sh?articleId=1234
>>
>> Might be handled something like this: -
>>
>> $ cat private.sh
>> #!/bin/bash
>>
>> # If we have no client certificate, request one.
>> if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
>>
>> echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
>>
>> elif [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) == "" ]];
>> then
>>
>> # We've never seen this user's client hash, so challenge for a PIN
>> # (we could store this current URL for onward forwarding)
>> echo -ne "30 /cgi-bin/login.sh\r\n"
>>
>> else
>>
>> echo -ne "20 text/gemini\r\n"
>> echo "This is the prize inside the protected resource!"
>> fi
>>
>> I think a redirect to a login process is unavoidable, because any
>> originating request might have its own query_string, yet we're going to
>> need one for the password prompt response. So the login.sh would be our
>> one-time verification to pin the certificate to a CN based user-id.
>>
>> $ cat login
>> #!/bin/bash
>>
>> # If we have no client certificate, request one.
>> if [[ "${TLS_CLIENT_HASH}" == "" ]]; then
>> echo -ne "60 CLIENT CERTIFICATE REQUIRED\r\n"
>> exit
>> fi
>>
>> # If the certificate has no CN, then reject it
>> if [[ "${REMOTE_USER}" == "" ]]; then
>> echo -ne "20 text/gemini\r\n"
>> echo "Your CN can't be used as a user-id!"
>> exit
>> fi
>>
>> # We have a client certificate, is it already authorised?
>> if [[ $(grep "${TLS_CLIENT_HASH}" /tmp/${REMOTE_USER}_sigs) != "" ]]; then
>> echo -ne "20 text/gemini\r\n"
>> echo "You are already authorised!"
>> exit
>> fi
>>
>> # We have a certificate and a valid user-id (CN), so either prompt for
>> # a PIN, or verify PIN if we've been given a QUERY_STRING.
>>
>> # Grep the remote user's line from the passwd file (format CN:PIN)
>> PWD_ENTRY=$(grep "^${REMOTE_USER}:" login_passwd)
>>
>> # Strip the CN value and separator, leaving the PIN
>> MY_PIN="${PWD_ENTRY#${REMOTE_USER}:}"
>>
>> # Check for our PIN in the query string (which may be empty)
>> if [[ "${QUERY_STRING}" == "${MY_PIN}" ]]; then
>> echo -ne "20 text/gemini\r\n"
>> echo "Your PIN checks out, ${REMOTE_USER}!"
>> echo "${TLS_CLIENT_HASH}" >>/tmp/${REMOTE_USER}_sigs
>> echo "Your hash has been stored in '/tmp/${REMOTE_USER}_sigs'"
>> exit
>> fi
>>
>> echo -ne "11 Please enter your PIN, ${REMOTE_USER}\r\n"
>>
>>
>> On Sun, 19 Jul 2020 at 20:26, Peter Vernigorov <pitr.vern at gmail.com>
>> wrote:
>>
>>> I am trying to implement a simple authentication for my Gemini site,
>>> and was planning to use a client certificate CN field to pass
>>> username:password pair to server. However, upon reading closely about
>>> the TLS handshake -
>>> https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake -
>>> it seems that the client (just like the server) certificate is sent
>>> before the ChangeCipherSpec record, i.e. insecure. That means to me
>>> that the CN field would be passed before the TLS session is started
>>> and therefore not suitable as an authentication medium. Is that
>>> correct?
>>>
>>> Another alternative to implement username/password type authentication
>>> in Gemini would be the sensitive input status code, but then I would
>>> have to store a list of certificate fingerprint and username pairs,
>>> greatly complicating the system.
>>>
>>> Given that Gemini protocol strives to be minimal/low-cost for both
>>> users and client/server devs, has anyone found a simple way to
>>> implement username/password type authentication systems? To be fair, I
>>> have attempted to use client short-/long-lived client certificates as
>>> per recommendation in Gemini protocol specification; however, if
>>> access to the same "account" from multiple devices and being able to
>>> survive certificate loss without permanently losing access is my
>>> account are requirements, this authentication method quickly becomes a
>>> mess. For example, think about how one would go about getting access
>>> to their astrobotany plant on a new device. This is why I ended up
>>> going back to username/password authentication, but having
>>> difficulties making sure that everything is secure. In need of
>>> help/suggestions/ideas, thanks.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200720/c699
483b/attachment.htm>
On Mon Jul 20, 2020 at 11:27 PM CEST, Peter Vernigorov wrote: > But I think the bigger problem is that now I need to store usernames, > pins, > all of user?s cert fingerprints and their first seen and last seen > dates, I > would need to build an interface to delete old/lost fingerprints, etc. Combining username/password authentication with multiple simultaneous, long-lived certificates seems like a maximum-complexity approach to me and I'm not sure there's much to be gained from it. If you want something light and simple using usernames and passwords, it makes sense to me to inform the user to generate a short-lived certificate, to then use a sequence of 10 and 11 status codes to request a username and password, and, if they are valid, to mark that certificate fingerprint as authorised for that account and at the same time immediately deauthorise (and forget about) any and all previous certificates used for that account. A user "logs out" manually by deleting the certificate, or else their session naturally expires when the certificate's validity period lapses. I grant you this is less straightforward than HTTP basic auth. Multi-user applications with user-friendly interfaces aren't really straightforward in Gemini. Cheers, Solderpunk
I'm hoping to collect pieces of advice that apply to all future developers on a wiki... I hope you're OK with that? gemini://transjovian.org/phoebe/page/Design The first post is a copy of Solderpunk's suggestion on how to do usernames and passwords. I'd love it if other people also helped collect these, or comment and refine them, as we all learn more.
I think the idea of collating mailing-list posts on particular subjects could be useful, though to add value it really needs commentary to summarise the posts and, perhaps more importantly, links to the relevant posts. I'd certainly want to see links to my original posts if I'm mentioned in reference but otherwise, as far as I'm concerned, if you're happy to curate stuff, then great! Kevin On Tue, 21 Jul 2020 at 20:37, Alex Schroeder <alex at gnu.org> wrote: > I'm hoping to collect pieces of advice that apply to all future > developers on a wiki... I hope you're OK with that? > > gemini://transjovian.org/phoebe/page/Design > > The first post is a copy of Solderpunk's suggestion on how to do > usernames and passwords. > > I'd love it if other people also helped collect these, or comment and > refine them, as we all learn more. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200721/c7e5 0757/attachment.htm>
On Tue, 2020-07-21 at 21:48 +0100, Kevin Sangeelee wrote: > I think the idea of collating mailing-list posts on particular > subjects > could be useful, though to add value it really needs commentary to > summarise the posts and, perhaps more importantly, links to the > relevant > posts. Yeah, absolutely. > I'd certainly want to see links to my original posts if I'm mentioned > in > reference but otherwise, as far as I'm concerned, if you're happy to > curate > stuff, then great! I'll try and remember to post the links. I've added a second post to the Design page, with a longer thread summary and a post of mine I felt was worth preserving: https://transjovian.org:1965/phoebe/page/Design https://transjovian.org:1965/phoebe/page/How%20to%20leave%20a%20comment As it is a wiki, obviously everybody is invited. One way to edit stories is using one of the options described here: https://transjovian.org:1965/page/Writing
Thanks Alex for setting up the design patterns wiki page. Although I think Kevin?s proposal is more complete with examples. I don?t necessary agree that existing certificate should be deleted, which logs user out on their other device, but of course it makes sense if server administrator wants to keep it as simple as possible. Perhaps this is something that could be configurable. On Tue, Jul 21, 2020 at 22:48 Kevin Sangeelee <kevin at susa.net> wrote: > I think the idea of collating mailing-list posts on particular subjects > could be useful, though to add value it really needs commentary to > summarise the posts and, perhaps more importantly, links to the relevant > posts. > > I'd certainly want to see links to my original posts if I'm mentioned in > reference but otherwise, as far as I'm concerned, if you're happy to curate > stuff, then great! > > Kevin > > > On Tue, 21 Jul 2020 at 20:37, Alex Schroeder <alex at gnu.org> wrote: > >> I'm hoping to collect pieces of advice that apply to all future >> developers on a wiki... I hope you're OK with that? >> >> gemini://transjovian.org/phoebe/page/Design >> >> The first post is a copy of Solderpunk's suggestion on how to do >> usernames and passwords. >> >> I'd love it if other people also helped collect these, or comment and >> refine them, as we all learn more. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200721/48b2 1cd5/attachment.htm>
For those who need this functionality, I have implemented the suggested flow in Gig framework, see https://github.com/pitr/gig#usernamepassword-authentication-middleware for the guide on how to use it. On Tue, Jul 21, 2020 at 11:53 PM Peter Vernigorov <pitr.vern at gmail.com> wrote: > > Thanks Alex for setting up the design patterns wiki page. Although I think Kevin?s proposal is more complete with examples. I don?t necessary agree that existing certificate should be deleted, which logs user out on their other device, but of course it makes sense if server administrator wants to keep it as simple as possible. Perhaps this is something that could be configurable. > > On Tue, Jul 21, 2020 at 22:48 Kevin Sangeelee <kevin at susa.net> wrote: >> >> I think the idea of collating mailing-list posts on particular subjects could be useful, though to add value it really needs commentary to summarise the posts and, perhaps more importantly, links to the relevant posts. >> >> I'd certainly want to see links to my original posts if I'm mentioned in reference but otherwise, as far as I'm concerned, if you're happy to curate stuff, then great! >> >> Kevin >> >> >> On Tue, 21 Jul 2020 at 20:37, Alex Schroeder <alex at gnu.org> wrote: >>> >>> I'm hoping to collect pieces of advice that apply to all future >>> developers on a wiki... I hope you're OK with that? >>> >>> gemini://transjovian.org/phoebe/page/Design >>> >>> The first post is a copy of Solderpunk's suggestion on how to do >>> usernames and passwords. >>> >>> I'd love it if other people also helped collect these, or comment and >>> refine them, as we all learn more. >>> >>>
---