| run |
29 min
|
|
3.3 miles
|
run |
Phew! After long awaited anticipation, I’ve built in a draft version of automated webmentions into my site, so now when I like and reply things from my Social Reader my site will send out a webmention immediately. No more 1-2 delays in my replies 😁🎉
DΛVID V3.0.5
https://davidwolfpaw.com/
•
Jul 5
Carl Hancock 🚀
http://www.gravityforms.com
•
Jul 5
Jamey Sharp
https://toot.cat/@jamey
•
Jul 5
I want to build a quick little web site for a thing and I'm facing analysis paralysis over which programming language to write it in, augh 😠
A change in the Microformats parsing spec from a few months ago reduced the cases where parsers would auto-generate a name property if there wasn't one in the original markup.
Previously, when the name was autogenerated, people ended up having to add an explicit name property to the HTML in order to avoid weird broken-looking names. Now that this change is approved and implemented in a couple parsers, things are working a lot better. I believe the Ruby parser has not yet implemented this change, but it's in the Python and PHP ones.
Certainly one option is Mastodon could just remove the p-name class, since the newer parsers would end up seeing those posts with just the summary and content properties.
Since afaik no Microformats consumers have the concept of CW/spoiler posts yet, this does raise the issue of how to provide a good fallback behavior for consumers that don't understand spoiler posts. My thought with moving the p-name class to the same element as p-summary is that the current consumers will see it as an "article", most likely only showing the name of the article. Here's an example of how my site renders comments that have a name (whether or not there is also summary or content)
Similarly, here's what my site shows when I'm replying to a post that has a name:
If the p-name class is used only for the CW/spoiler preview text, then my site wouldn't show the full content in either the reply context or as a comment, which seems like the safest fallback behavior.
Posts with no CW would end up with just a content property. According to the new parsing rules, those look just like normal content-only posts and sites don't see a name property and treat them as normal text/microblog/toot/tweet posts.
Gargron
https://github.com/Gargron
•
Jul 6
Yep I just discovered that. Could just remove those particular tests...
00dani
https://github.com/00dani
•
Jun 26
An alternative possibility would be to prescribe the format of IndieAuth access codes, as part of the standard. For instance, we could prefix the usual arbitrary implementation-specific access code blob with the expected me value, making it easy for token endpoints to discover the correct authorization endpoint. code=https://00dani.me/$C5r1cuqJk1fUTGrWX4DPHz44jxpgHF or something like that. Then, of course, pure OAuth 2.0 clients would pass through that extra piece of information with no trouble whatsoever, since it's embedded in an existing standard parameter.
It's certainly a messy approach, though, and one might question whether OAuth client compatibility is worth adding this complexity to IndieAuth. Additionally, making a change like this now would introduce potential incompatibility: a token endpoint that knows it can pull information out of the access code might still receive an access code from an authorization endpoint that doesn't embed information in the prescribed format, for instance.
Still, prescribing a format for access codes might not be quite as unreasonable as it seems: after all, client IDs are also treated as opaque in pure OAuth 2.0, whereas in IndieAuth they have a prescribed and meaningful format.
tl;dr The more I think about it, the more I think this parameter enables a use case that isn't really necessary. The me parameter in the code exchange step specifically allows for a token endpoint to be detached from both the Micropub endpoint and the authorization endpoint.
Full details below.
The different use cases that are all supported right now:
This is the simplest case in terms of architecture, but the most amount of work for a developer. In this case, someone writes all three parts of the system. Since they are part of the same system, the mechanism by which the token endpoint validates authorization codes does not need to be standardized, it's all internal.
Both my website and the Wordpress IndieAuth plugin fall under this case.
In this case, someone is building a CMS that includes a Micropub endpoint as well as a token endpoint. However, they want to speed up their development, so they use an authorization endpoint service such as indieauth.com.
The client sends the auth code to the token endpoint, and since the token endpoint is part of the CMS, it already knows the only place it can go to validate the auth code is the authorization endpoint service that it's configured to use. Therefore there is no need for the me parameter, which normally tells the token endpoint where to go to verify the auth code.
Specifically this case is where a service provides both an authorization endpoint and token endpoint. This is the quickest path to building a Micropub endpoint, since all you need to do is build out the Micropub endpoint itself, and when any requests come in with a token, the endpoint goes and checks whether the token is valid by testing it against the token endpoint service.
This is a very common case with peoples' individual websites, as it offloads the development and maintenance of the security bits to a service. I provide these as a service at indieauth.com and tokens.indieauth.com.
The interesting thing though is that when a single service provides both, there is also no need for the me parameter at the code exchange step, since the token endpoint already knows where it needs to verify the authorization code since the code was issued by the same system.
The only case where the me is needed is when the authorization endpoint and token endpoint are both used as services and they are separate services. Imagine a standalone token endpoint service: the job of this service is to verify authorization codes and issue access tokens, and later verify access tokens. In this situation, a request comes in with an unknown authorization code and it needs to verify it. Since it was not part of the system that issued the code, it needs to know how to verify it. Right now, this is enabled because this request also includes the me parameter, so the token endpoint goes and looks up the user's authorization endpoint and verifies the code there.
The thing I'm realizing though is that this is really quite an edge case, and one that I don't think is actually very important. Typically someone who is building a Micropub endpoint themselves will first start by using an authorization/token endpoint service, and there is no benefit to them if those are two separate services. In fact it's probably easier if they are just part of the same system since it's less moving parts to think about at this stage.
Later, that person can decide they want to take over issuing tokens, but still don't want to build out the UI of an authorization service. At this point, they fall under the second use case above. They build out a token endpoint into their software, and since they're using the authorization endpoint service they know where to verify authorization codes.
On the other end of the spectrum, you have people who build the whole thing out themselves, like my website and the Wordpress plugin. In these cases the me is completely irrelevant in the code exchange step.
The particular situation that the me enables is using a separate service for the authorization and token endpoints, and I can't think of a case where that is actually important.
Aaron Parecki
https://aaronparecki.com/
•
Jul 5
tl;dr The more I think about it, the more I think this parameter enables a use case that isn't really necessary. The me parameter in the code exchange step specifically allows for a token endpoint to be detached from both the Micropub endpoint and the authorization endpoint.
Full details below.
The different use cases that are all supported right now:
This is the simplest case in terms of architecture, but the most amount of work for a developer. In this case, someone writes all three parts of the system. Since they are part of the same system, the mechanism by which the token endpoint validates authorization codes does not need to be standardized, it's all internal.
Both my website and the Wordpress IndieAuth plugin fall under this case.
In this case, someone is building a CMS that includes a Micropub endpoint as well as a token endpoint. However, they want to speed up their development, so they use an authorization endpoint service such as indieauth.com.
The client sends the auth code to the token endpoint, and since the token endpoint is part of the CMS, it already knows the only place it can go to validate the auth code is the authorization endpoint service that it's configured to use. Therefore there is no need for the me parameter, which normally tells the token endpoint where to go to verify the auth code.
Specifically this case is where a service provides both an authorization endpoint and token endpoint. This is the quickest path to building a Micropub endpoint, since all you need to do is build out the Micropub endpoint itself, and when any requests come in with a token, the endpoint goes and checks whether the token is valid by testing it against the token endpoint service.
This is a very common case with peoples' individual websites, as it offloads the development and maintenance of the security bits to a service. I provide these as a service at indieauth.com and tokens.indieauth.com.
The interesting thing though is that when a single service provides both, there is also no need for the me parameter at the code exchange step, since the token endpoint already knows where it needs to verify the authorization code since the code was issued by the same system.
The only case where the me is needed is when the authorization endpoint and token endpoint are both used as services and they are separate services. Imagine a standalone token endpoint service: the job of this service is to verify authorization codes and issue access tokens, and later verify access tokens. In this situation, a request comes in with an unknown authorization code and it needs to verify it. Since it was not part of the system that issued the code, it needs to know how to verify it. Right now, this is enabled because this request also includes the me parameter, so the token endpoint goes and looks up the user's authorization endpoint and verifies the code there.
The thing I'm realizing though is that this is really quite an edge case, and one that I don't think is actually very important. Typically someone who is building a Micropub endpoint themselves will first start by using an authorization/token endpoint service, and there is no benefit to them if those are two separate services. In fact it's probably easier if they are just part of the same system since it's less moving parts to think about at this stage.
Later, that person can decide they want to take over issuing tokens, but still don't want to build out the UI of an authorization service. At this point, they fall under the second use case above. They build out a token endpoint into their software, and since they're using the authorization endpoint service they know where to verify authorization codes.
On the other end of the spectrum, you have people who build the whole thing out themselves, like my website and the Wordpress plugin. In these cases the me is completely irrelevant in the code exchange step.
The particular situation that the me enables is using a separate service for the authorization and token endpoints, and I can't think of a case where that is actually important.
Here's a quick survey of current implementations of token endpoints:
me parameter exists, but does not use it for anythingme parameter exists, but does not use it for anything sourceme parameter detailsme parameter sourceme parameter sourceme parameter sourceme in the request. not strictly necessary since it ends up using the me that is stored with the authorization code anyway. sourceme parameter exists, but does not use it sourceme to find the authorization endpoint to verify the code source
me to find the authorization endpoint, but only allows a whitelisted set of endpoints to be used source readme
me parameter enables this feature.
