423 Matching Annotations
  1. Last 7 days
    1. The “work around” was to detect users in an IAB and display a message on first navigation attempt to prompt them to click the “open in browser” button early.

      That's a pretty deficient workaround, given the obvious downsides. A more robust workaround would be to make the cart stateless, as far as the server is concerned, for non-logged-in users; don't depend on cookies. A page request instead amounts to a request for the form that has this and this and this pre-selected ("in the cart"). Like with paper.

  2. Aug 2022
  3. Jul 2022
    1. To synchronize BMC Helix common services container images

      I've tried to run this section while harbor runs on http. This fails as docker login command is issued and thinks harbor is on SSL.

      The workaround is to do the following

      1. Create 4 replication rules.

      Name ade_part_01 Source resource registry https://containers.bmc.com Source resource filter Name bmc/lp0lz Source resource filter Tag {4.2.2-debian-10-r50,ade-authz-service-149,ade-file-service-e2830be-7,ade-identity-management-portal-12,ade-identity-management-service-15,ade-notification-service-9,adeops-util-v012,adeops-util-v013,adeops-util-v016,adeops-util-v019,adeops-util-v024,adereporting-21.3.02.02,adereporting-content-e0ab22f-251,adereporting-initdb-v001,adereporting-kafkacli-v002,adereporting-puller-7e41b3d-274,adereporting-renderer-dd91f81-216,adereporting-runner-7e41b3d-274,ade-tenant-management-automation-273,ade-tenant-management-portal-14,ade-tenant-management-service-7,ade-ui-content-service-18,aif-api-service-8150462-9,aif-clustering-ingestion-service-3a4ce1d-12,aif-clustering-query-service-3dfbda3-9,aif-clustering-service-08fa171-9,aif-core-service-fdfb78d-6,aif-incident-ingestion-service-3a0f0e2-8,aif-job-manager-service-ab85bfb-8,aif-machine-learning-utilities-8a08716-57,aif-ticket-service-d71f457-11,anomaly-detection-service-58e6996-5}

      Name ade_part_02 Source resource registry https://containers.bmc.com Source resource filter Name bmc/lp0lz Source resource filter Tag {authproxy-RSSO_Auth_Proxy_101,authproxy-RSSO_Auth_Proxy_110,authproxy-RSSO_Auth_Proxy_112,authproxy-RSSO_Auth_Proxy_80,bitnami-kafka-2.7.0-debian-10-r124,bitnami-minio-2021.4.18-debian-10-r0,bitnami-zookeeper-3.7.0-debian-10-r25,custom-elasticsearch-1.13.3,custom-postgresql-repmgr-12.9.0,custom-sec-ade-infra-clients-1,custom-sec-redis-5.0.12-alpine,custom-sec-victoriametrics-vminsert-v1.63.0-cluster,custom-sec-victoriametrics-vmselect-v1.63.0-cluster,custom-sec-victoriametrics-vmstorage-v1.63.0-cluster,es-proxy-nginx-service-6d2eb81-6,es-proxy-service-6d2eb81-6,event-ingestion-service-4c0353c-4,event-mgmt-service-fc008be-6,event-processor-service-199851c-10,event-service-a21ce51-7,haproxy-2.0.4,justwatch-elasticsearch_exporter-1.1.0,kibana-proxy-service-c4f46f6-6,kibana-service-c4f46f6-6,kubectl-latest,log-ingestion-service-ff04217-99,log-mgmt-service-ceb53d1-4,log-processing-service-726afae-6,logs-portal-eb0d3a5-8}

      Name ade_part_02 Source resource registry https://containers.bmc.com Source resource filter Name bmc/lp0lz Source resource filter Tag {metric-aggregation-service-6c4b171-9,metric-configuration-service-2b5ba78-7,metric-gateway-service-4a6caae-8,metricservice-6b50628-8,prometheus-ingestion-service-8659793-7,RSSO_21.3.00-DRRS0-3893,smart-graph-api-r841442-642-daas_ship-tkn_ship,smart-graph-controller-api-r841442-642-daas_ship-tkn_ship,smart-graph-controller-efsinit-r841442-642-daas_ship-tkn_ship,smart-graph-controller-security-r841442-642-daas_ship-tkn_ship,smart-graph-environment-controller-r841442-642-daas_ship-tkn_ship,smart-graph-instance-controller-r841442-642-daas_ship-tkn_ship,tctlrest-14,thirdparty-ingestion-service-6add794-5,truesight-credential-service-267,truesight-featureflag-service-272,0.9.0-debian-10-r35,bitnami-shell-10,bitnami-bitnami-shell-10-debian-10-r61,custom-sec-busybox-1.27.2,webhook-2102_20210218,elasticsearch-7.16.2-debian-10-r0,bitnami-elasticsearch-curator-5.8.4,kibana-7.16.2-debian-10-r0,fluentd-1.12.3-debian-10-r4}

      Name ade_part_02 Source resource registry https://containers.bmc.com Source resource filter Name bmc/lp0lz Source resource filter Tag {ade-ims-webhook-114,ade-itsm-identity-sync-199}

      1. Then you can synchronize them at will
    2. Install Harbor by using self signed SSL certificates.

      This step is not mandatory as even harbor mentions:

      However, using HTTP is acceptable only in air-gapped test or development environments that do not have a connection to the external internet.

    3. wget https://github.com/goharbor/harbor/releases/download/v2.1.4/harbor-offline-installer-v2.1.4.tgz

      I've used curl -L https://storage.googleapis.com/harbor-releases/release-1.8.0/harbor-offline-installer-v1.8.0.tgz > harbor-offline-installer-v1.8.0.tgz

      which is the minimal required version

    4. harbor.yml.tmpl harbor.yml

      the minimal required version doesn't need this step only one harbor.yml file is available

      The file needs to change in one variable: hostname

      the https port is not enabled

      you may also change the harbor admin password

    1. ```bash POST /news/comments/5 HTTP/1.1 Content-Type: text/xml

      <item> <title>Foo Bar</title> <author>joe@bitworking.org</author> <link>http://www.bar.com/</link> <description>My Excerpt</description> </item> ```

  4. Jun 2022
  5. May 2022
    1. 4.1 RDF/XML Service Description

      ```bash

      Given the HTTP request:

      GET /sparql/ HTTP/1.1 Host: www.example

      the SPARQL service responds with an RDF/XML encoded

      service description (no content negotiation or RDFa

      encoding is used):

      HTTP/1.1 200 OK Date: Fri, 09 Oct 2009 17:31:12 GMT Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3 Connection: close Content-Type: application/rdf+xml

      <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:sd="http://www.w3.org/ns/sparql-service-description#" xmlns:prof="http://www.w3.org/ns/owl-profile/" xmlns:void="http://rdfs.org/ns/void#"> <sd:Service> <sd:endpoint rdf:resource="http://www.example/sparql/"/> <sd:supportedLanguage rdf:resource="http://www.w3.org/ns/sparql-service-description#SPARQL11Query"/> <sd:resultFormat rdf:resource="http://www.w3.org/ns/formats/RDF_XML"/> <sd:resultFormat rdf:resource="http://www.w3.org/ns/formats/Turtle"/> <sd:feature rdf:resource="http://www.w3.org/ns/sparql-service-description#DereferencesURIs"/> <sd:defaultEntailmentRegime rdf:resource="http://www.w3.org/ns/entailment/RDFS"/> <sd:extensionFunction> <sd:Function rdf:about="http://example.org/Distance"/> </sd:extensionFunction> <sd:defaultDataset> <sd:Dataset> <sd:defaultGraph> <sd:Graph> <void:triples rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">100</void:triples> </sd:Graph> </sd:defaultGraph> <sd:namedGraph> <sd:NamedGraph> <sd:name rdf:resource="http://www.example/named-graph"/> <sd:entailmentRegime rdf:resource="http://www.w3.org/ns/entailment/OWL-RDF-Based"/> <sd:supportedEntailmentProfile rdf:resource="http://www.w3.org/ns/owl-profile/RL"/> <sd:graph> <sd:Graph> <void:triples rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">2000</void:triples> </sd:Graph> </sd:graph> </sd:NamedGraph> </sd:namedGraph> </sd:Dataset> </sd:defaultDataset> </sd:Service> </rdf:RDF> ```

    1. Signposting is an approach to make the scholarly web more friendly to machines. It uses Typed Links as a means to clarify patterns that occur repeatedly in scholarly portals. For resources of any media type, these typed links are provided in HTTP Link headers. For HTML resources, they may additionally be provided in HTML link elements. Throughout this site, examples use the former approach.

      http HTTP/1.1 302 Found Server: Apache-Coyote/1.1 Vary: Accept Location: http://www.dlib.org/dlib/november15/vandesompel/11vandesompel.html Link: <http://orcid.org/0000-0002-0715-6126> ; rel="author", <http://orcid.org/0000-0003-3749-8116> ; rel="author" Expires: Tue, 31 May 2016 17:18:50 GMT Content-Type: text/html;charset=utf-8 Content-Length: 217 Date: Tue, 31 May 2016 16:38:15 GMT Connection: keep-alive

  6. datatracker.ietf.org datatracker.ietf.org
    1. 4. Link Relations for Web Services

      In order to allow Web services to represent the relation of individual resources to service documentation/description and metadata, this specification introduces and registers three new link relation types.

      4.1. The service-doc Link Relation Type

      The "service-doc" link relation type is used to represent the fact that a resource or a set of resources is documented at a specific URI. The target resource is expected to provide documentation that is primarily intended for human consumption.

      4.2. The service-desc Link Relation Type

      The "service-desc" link relation type is used to represent the fact that a resource or a set of resources is described at a specific URI. The target resource is expected to provide a service description that is primarily intended for machine consumption. In many cases, it is provided in a representation that is consumed by tools, code libraries, or similar components.

      4.3. The service-meta Link Relation Type

      The "service-meta" link relation type is used to link to available metadata for the service context of a resource. Service metadata is any kind of data that may be of interest to existing or potential service users, with documentation/description being only two possible facets of service metadata. The target resource is expected to provide a representation that is primarily intended for machine consumption. In many cases, it is provided in a representation that is consumed by tools, code libraries, or similar components.

      Since service metadata can have many different purposes and use many different representations, it may make sense for representations using the "service-meta" link relation to offer additional hints about the specific kind or format of metadata that is being linked.

      This definition of the "service-meta" link relation makes no specific assumptions about how these link hints will be represented, and the specific mechanism will depend on the context where the "service-meta" link relation is being used.

      One example is that a "service-desc" link may identify an OpenAPI description, which is supposed to be the machine-readable description of a Web API. A "service-meta" link may identify a resource that contains additional metadata about the Web API, such as labels that classify the API according to a labeling scheme and a privacy policy that makes statements about how the Web API manages personally identifiable information.

  7. Apr 2022
    1. Cache using fetch

      Determine how to cache a resource by setting TTLs, custom cache keys, and cache headers in a fetch request.

      ```js async function handleRequest(request) { const url = new URL(request.url);

      // Only use the path for the cache key, removing query strings // and always store using HTTPS, for example, https://www.example.com/file-uri-here const someCustomKey = https://${url.hostname}${url.pathname};

      let response = await fetch(request, { cf: { // Always cache this fetch regardless of content type // for a max of 5 seconds before revalidating the resource cacheTtl: 5, cacheEverything: true, //Enterprise only feature, see Cache API for other plans cacheKey: someCustomKey, }, }); // Reconstruct the Response object to make its headers mutable. response = new Response(response.body, response);

      // Set cache control headers to cache on browser for 25 minutes response.headers.set('Cache-Control', 'max-age=1500'); return response; }

      addEventListener('fetch', event => { return event.respondWith(handleRequest(event.request)); }); ```


      Caching HTML resources

      Setting the cache level to Cache Everything will override the default cacheability of the asset. For time-to-live (TTL), Cloudflare will still rely on headers set by the origin.

      js // Force Cloudflare to cache an asset fetch(event.request, { cf: { cacheEverything: true } });

    1. hopefully feed readers can treat permanent redirects as a sign to permanently update their feed URLs, then I can remove it. They probably don't, much like bookmarks don't
  8. Mar 2022
    1. Abstract This document defines two new HTTP headers "Content-Profile" and "Accept-Profile" that enable User Agents and hosts to indicate and negotiate the profile used for representing a specific resource. In this context, a profile is a description of the structural and/or semantic constraints of a group of documents in addition to the syntactical interpretation provided by more generic MIME types. Examples of profiles include Dublin Core Application Profiles, XML Schemata, and RDF Shape Expressions. This document further defines and registers the "profile" parameter for the HTTP "Link" header and suggests a best practice for the use of the new headers together with the "Link" header for the purposes of performing content negotiation and pointing clients to alternate representations.
    1. logout

      This should be a button. (GET should be idempotent and free of side effects.)

  9. Feb 2022
    1. Integrating AbortController

      js export const Timeout = (time) => { let controller = new AbortController(); setTimeout(() => controller.abort(), time * 1000); return controller; }

      ```js import { useEffect, useState } from "react"; //imports goes here

      export default function App() { //state goes here

      //update useEffect(() => { fetch("https://jsonplaceholder.typicode.com/todos/1", { signal: Timeout(10).signal }) .then((resp) => resp.json()) .then((resp) => setData(resp)) .catch((err) => setError(true)); return () => {}; }, []); return ( <div> {* JSX goes here*} </div> ); } ```

    1. 2. Timeout a fetch() request

      ```js async function fetchWithTimeout(resource, options = {}) { const { timeout = 8000 } = options;

      const controller = new AbortController(); const id = setTimeout(() => controller.abort(), timeout); const response = await fetch(resource, { ...options, signal: controller.signal<br /> }); clearTimeout(id); return response; }

      async function loadGames() { try { const response = await fetchWithTimeout('/games', { timeout: 6000 }); const games = await response.json(); return games; } catch (error) { // Timeouts if the request takes // longer than 6 seconds console.log(error.name === 'AbortError'); } } ```

  10. Jan 2022
    1. This specification defines two formats and respective media types for representing sets of links as stand-alone documents. One format is JSON-based, the other aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support discovery of sets of links.
      GET links/resource1 HTTP/1.1
      Host: example.org
      Accept: application/linkset+json
      
      HTTP/1.1 200 OK
      Date: Mon, 12 Aug 2019 10:46:22 GMT
      Server: Apache-Coyote/1.1
      Content-Type: application/linkset+json
      Link: <https://example.org/links/resource1>
            ; rel="alternate"
            ; type="application/linkset"
      Content-Length: 1349
      
      { "linkset":
        [
          { "anchor": "https://example.org/resource1",
            "author": [
              { "href": "https://authors.example.net/johndoe",
                "type": "application/rdf+xml"
              }
            ],
            "memento": [
              { "href": "https://example.org/resource1?version=1",
                "type": "text/html",
                "datetime": "Thu, 13 Jun 2019 09:34:33 GMT"
              },
              { "href": "https://example.org/resource1?version=2",
                "type": "text/html",
                "datetime": "Sun, 21 Jul 2019 12:22:04 GMT"
              }
            ],
            "latest-version": [
              { "href": "https://example.org/resource1?version=3",
                "type": "text/html"
              }
            ]
          },
          { "anchor": "https://example.org/resource1?version=3",
            "predecessor-version": [
              { "href": "https://example.org/resource1?version=2",
                "type": "text/html"
              }
            ]
          },
          { "anchor": "https://example.org/resource1?version=2",
            "predecessor-version": [
              { "href": "https://example.org/resource1?version=1",
                "type": "text/html"
              }
            ]
          },
          { "anchor": "https://example.org/resource1#comment=1",
            "author": [
              { "href": "https://authors.example.net/alice"}
            ]
          }
        ]
      }
      
    1. 4. Robustifying a link when linking to a specific version

      If the main intent is to link to a specific state of an original resource, for example a snapshot of the original resource in a web archive or one of its version in a version control system, then Robust Link information is conveyed as follows:

      • href for the URI that provides the specific state i.e., the snapshot or resource version;
      • data-originalurl for the URI of the original resource;
      • data-versiondate for the datetime of the snapshot or resource version.

      [...]

      <a href="http://en.wikipedia.org/w/index.php?title=Web_archiving&oldid=485347845"
         data-originalurl="http://en.wikipedia.org/wiki/Web_archiving"
         data-versiondate="2012-03-20">Robust Link to this specific version of the Wikipedia page</a>
      
    2. 3. Robustifying a link when linking to the original resource

      If the main intent is to link to an original resource but also allow future users of that link to see the state of the original resource around the time the link was put in place, then Robust Link information is conveyed as follows:

      • href for the URI of the original resource for which the snapshot was taken;
      • data-versionurl for the URI of the snapshot;
      • data-versiondate for the datetime of linking, of taking the snapshot.

      [...]

      <a href="http://www.w3.org/"
         data-versionurl="https://archive.today/r7cov"
         data-versiondate="2015-01-21">Robust Link to the W3C home page</a>
      
    3. The approach proposed here is to convey this information on a link by leveraging HTML5's attribute extensibility mechanism. It introduces the following data- attributes for the anchor (<a>) element:

      • data-originalurl for the URI of the original resource;
      • data-versionurl for the URI of the snapshot;
      • data-versiondate for the datetime of linking, of taking the snapshot.
    4. Robust Links provide multiple pathways to revisit a link's original content, even a long time after the link was put in place. This document describes approaches to robustify links in HTML pages. All approaches assume that, when linking to a web resource, a snapshot of the state of that resource is created, for example, in a web archive or a versioning system. When linking, the URI of the resource, the URI of the snapshot, and the datetime of linking are conveyed.
    1. The most obvious time you'd encounter a 401 error, on the other hand, is when you have not logged in at all, or have provided the incorrect password.
    2. As mentioned in the previous article, the 403 error can result when a user has logged in but they don't have sufficient privileges to access the requested resource. For example, a generic user may be attempting to load an 'admin' route.
    1. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.

      Meaning that 99% of the people use it are using it "wrong" because they're not using it for HTTP authentication and don't send a WWW-Authenticate header field with their 401 response?

      Hmm. That's a tough one. On the one hand, the spec does say they must send it.

      Initial opinion

      But on the other hand, one could argue that that requirement only applies if using 401 for HTTP authentication. And that saying it's wrong to do so (as they claim at https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses/14713094#14713094 and https://hyp.is/JA45zHotEeybDdM_In4frQ/stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses) is having a too strict/narrow/literal interpretation.

      HTTP is meant to be used widely in many very different uses and contexts, most of which do not use this very specific HTTP authentication scheme; my opinion is that they shouldn't be denied from using it, just because they don't have anything useful WWW-Authenticate header field. (Or (which is also fine with me), just put something "emptyish" in the field, like "Unused". Unless that would trigger a Basic auth modal in the browser, in which case we shouldn't, for practical reasons.)

      Why shouldn't we be able to repurpose this same status code for uses that are still authentication, but just not HTTP authentication per se?

      Is it really wrong to repurpose this useful status code for other contexts, like cookie-based app-defined authentication systems?

      I say that it's okay to repurpose/reuse 401 for any authentication system (that uses HTTP as a part of it, even though not using HTTP's own authentication system), as long as we try to maintain the same semantic as originally intended/described here. I think it's okay to use 401 as a response to a XHR request, and then have the client redirect to a login page, which provides a way to authenticate again (reattempt the authentication challenge), analogous to how it works for HTTP authentication.

      Revised opinion

      https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses/14713094#14713094 has made me change my mind and convinced me that...

      Authentication by schemes outside of (not defined by) RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication should not use HTTP status 401, because 401 Unauthorized is only defined (by current RFCs) by RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication, and has semantics and requirements (such as the requirement that "A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge.") that simply don't make sense or cannot be fulfilled if using a non-HTTP authentication scheme.

      403 Forbidden, on the other hand, is defined by the broader HTTP standard, in RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content and RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication.

      In conclusion, if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.

      Couldn't a custom auth system use WWW-Authenticate header?

      The question was asked:

      Doesn't RFC7235 provide for "roll-your-own" or alternate auth challenges? Why can't my app's login flow present its challenge in the form of a WWW-Authenticate header? Even if a browser doesn't support it, my React app can...

      And I would say sure, if you want (and if the browser doesn't automatically show a Basic auth modal in this case and thwart your plans).

      They might be on to something here with that question!

      But that should probably be the test of whether you can/should use 401: are you actually using WWW-Authenticate header?

      Indeed I found an example where it is used for OAuth2.

    1. That comes in the form of the WWW-Authenticate header with the specific authentication scheme to use. For example, in the case of OAuth2, the response should look like the following:
    2. "The basic principle behind REST status code conventions is that a status code must make the client aware of what is going on and what the server expects the client to do next"
    3. You can fulfill this principle by giving answers to the following questions:Is there a problem or not?If there is a problem, on which side is it? On the client or on the server side?If there is a problem, what should the client do?
    4. Now, assume your client attempts to access a resource that it MUST NOT access at all, for example, because it belongs to another user. What status code should your API return? Should it return a 403 or a 401 status code?You may be tempted to return a 403 status code anyway. But, actually, you can't suggest any missing permission because that client has no way to access that resource. So, the 403 status code gives no actual helpful information. You may think that returning a 401 status code makes sense in this case. After all, the resource belongs to another user, so the request should come from a different user.However, since that resource shouldn't be reached by the current client, the best option is to hide it.
    5. Let's explore a different case now. Assume, for example, that your client sends a request to modify a document and provides a valid access token to the API. However, that token doesn't include or imply any permission or scope that allows the client to perform the desired action.In this case, your API should respond with a 403 Forbidden status code. With this status code, your API tells the client that the credentials it provided (e.g., the access token) are valid, but it needs appropriate privileges to perform the requested action.
    1. The difference is what the server expects the client to do next.
    2. Authentication by schemes outside of RFC2617 is not supported in HTTP status codes and are not considered when deciding whether to use 401 or 403.

      What does "are not considered when deciding whether to use 401 or 403" mean exactly? What exactly should not be considered, and what exactly should be considered instead? In other words, how did someone arrive at the conclusion that "if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used."? Why is 403 okay to use for non-HTTP authentication, but not 401?

      Oh, I think I understand the difference now.

      They should have said:

      Authentication by schemes outside of (not defined by) RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication should not use HTTP status 401, because 401 Unauthorized is only defined (by current RFCs) by RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication, and has semantics and requirements (such as the requirement that "A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge.") that simply don't make sense or cannot be fulfilled if using a non-HTTP authentication scheme.

      403 Forbidden, on the other hand, is defined by the broader HTTP standard, in RFC7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content and RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication.

      In conclusion, if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.

      See also my comments in https://hyp.is/p1iCnnowEeyUPl9PxO8BuQ/www.rfc-editor.org/rfc/rfc7235

    3. Meaning if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.
    4. If HTTP authentication is not in use and the service has a cookie-based authentication scheme as is the norm nowadays, then a 403 or a 404 should be returned.
    5. While this seems to me like it's probably an accurate interpretation of the old RFC 2616, note that RFC 7231 defines the semantics of a 403 differently, and in fact explicitly states that "The client MAY repeat the request with new or different credentials."
    6. it depends on the application but generally, if an authenticated user doesn't have sufficient rights on a resource, you might want to provide a way to change credentials or send a 401.

      A 403 doesn't tell the client / user agent what the next step is or provide a way to change credentials.

      So maybe a 302 redirect is the best answer after all? Even though it sadly lacks the nice semantic distinction that 401/403 provide...

    7. FORBIDDEN: Status code (403) indicating the server understood the request but refused to fulfill it. User/agent known by the server but has insufficient credentials. Repeating request will not work, unless credentials changed, which is very unlikely in a short time span.
    8. Send a 302 to your login-page

      That's typically what people do, isn't it.

      That answers the question "how do we best instruct the user agent to take the next step that is required". And maybe a redirect is in fact the best answer.

      See https://hyp.is/mDvXsHoxEeyHC0Ol9HE3CA/stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses

    9. The statement is "If the request already included Authorization credentials". That means if this is a response from a request which provided the credential (e.g. the response from a RFC2617 Authentication attempt). It is essentially to allow the server to say, "Bad account/password pair, try again". In the posed question, the user is presumably authenticated but not authorized. 401 is never the appropriate response for those circumstances.
    10. This may be because it is known that no level of authentication is sufficient (for instance because of an IP blacklist), but it may be because the user is already authenticated and does not have authority.
    11. 401 is only appropriate for HTTP Authentication
    12. I'm using both - the 401 for unauthenticated users, the 403 for authenticated users with insufficient permissions.
    13. From your use case, it appears that the user is not authenticated. I would return 401.
    14. There's a problem with 401 Unauthorized, the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please reauthenticate and try again.” To help you out, it will always include a WWW-Authenticate header that describes how to authenticate.
    15. So, for authorization I use the 403 Forbidden response. It’s permanent, it’s tied to my application logic, and it’s a more concrete response than a 401. Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”
    16. 401 'Unauthorized' should be 401 'Unauthenticated', problem solved !
    17. UNAUTHORIZED: Status code (401) indicating that the request requires authentication, usually this means user needs to be logged-in (session). User/agent unknown by the server. Can repeat with other credentials. NOTE: This is confusing as this should have been named 'unauthenticated' instead of 'unauthorized'.
    18. Checks are usually done in this order: 404 if resource is public and does not exist or 3xx redirection OTHERWISE: 401 if not logged-in or session expired 403 if user does not have permission to access resource (file, json, ...) 404 if resource does not exist or not willing to reveal anything, or 3xx redirection
    19. +----------------------- | RESOURCE EXISTS ? (if private it is often checked AFTER auth check) +----------------------- | | NO | v YES v +----------------------- 404 | IS LOGGED-IN ? (authenticated, aka user session) or +----------------------- 401 | | 403 NO | | YES 3xx v v 401 +----------------------- (404 no reveal) | CAN ACCESS RESOURCE ? (permission, authorized, ...) or +----------------------- redirect | | to login NO | | YES | | v v 403 OK 200, redirect, ... (or 404: no reveal) (or 404: resource does not exist if private) (or 3xx: redirection)
    20. I would expect that 401 to be named "Unauthenticated" and 403 to be named "Unauthorized". It is very confusing that 401, which has to do with Authentication,
    1. If the ticket is incorrect or damaged, you cannot even go through the airport security: when they check your ticket, it will be refused. You are Forbidden to enter the boarding area of the airport.

      It depends what we mean by "incorrect"/damaged "credentials ("ticket")...

      A. If they are invalid or incorrect in the sense that we can't authenticate them as anyone (as it sounds like you mean with "incorrect" or "damaged") (they're not a user in our database or the password doesn't match a user in our database), then you should actually use 401, meaning that the client can/should try (again) to authenticate with different credentials.

      B. But if by "incorrect" you mean (as it sounds like you mean with "you cannot even go through the airport security: when they check your ticket, it will be refused") that the credentials were valid enough to authenticate you as someone (a user in our database), but that (known( user has insufficient credentials, then correct, it should be a 403 forbidden.

      It's even easier to explain / think about if you just think of 401 as being used for any missing or failed authentication. See:

    2. These two sound pretty similar to me. And to make things even more confusing, 403 “Forbidden” says that the server refuses to “authorize” the request but it’s code 401 that is called “Unauthorized”. 😵
  11. datatracker.ietf.org datatracker.ietf.org
    1. If authentication credentials were provided in the request, the server considers them insufficient to grant access.
    1. 401 Unauthorized The requestor is not authorized to access the resource. This is similar to 402 but is used in cases where authentication is expected but has failed or has not been provided.
    1. You’d like to access the content of the resource but you’re not logged in (so not authenticated yet). The server will return you a 401 error. You need to log in to be able to access the resource.
    2. You’d like to delete the user, but you’re authenticated as a regular user, not as an admin. The server doesn’t allow regular users to perform such requests, so in the result, the server will send you a 403 error. Re-authentication won’t make any difference.
    1. <link rel="prefetch" href="/style.css" as="style" />
      <link rel="preload" href="/style.css" as="style" />
      <link rel="preconnect" href="https://example.com" />
      <link rel="dns-prefetch" href="https://example.com" />
      <link rel="prerender" href="https://example.com/about.html" />
      <link rel="modulepreload" href="/script.js" />
      
    1. function parseLinkHeader( linkHeader ) {
         const linkHeadersArray = linkHeader.split( ", " ).map( header => header.split( "; " ) );
         const linkHeadersMap = linkHeadersArray.map( header => {
            const thisHeaderRel = header[1].replace( /"/g, "" ).replace( "rel=", "" );
            const thisHeaderUrl = header[0].slice( 1, -1 );
            return [ thisHeaderRel, thisHeaderUrl ]
         } );
         return Object.fromEntries( linkHeadersMap );
      }