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.

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.

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."

the meaning of the status code has been rewritten beneath our feet. (Annoyingly, the Changes from RFC 2616 appendix doesn't acknowledge the change!)

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.

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.

Send a 302 to your login-page

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.

The RFC2617 model is one-user, one-credentials so the case where the user may have a second set of credentials that could be authorized may be ignored. It neither suggests nor implies that some sort of login page or other non-RFC2617 authentication protocol may or may not help - that is outside the RFC2616 standards and definition.

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.

Possibly there are authorizations that will permit access to the resource, possibly there are not, but let's give it a try and see what happens.

401 is only appropriate for HTTP Authentication

I'm using both - the 401 for unauthenticated users, the 403 for authenticated users with insufficient permissions.

From your use case, it appears that the user is not authenticated. I would return 401.

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.

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.”

status code 401 has been removed from that RFC

401 'Unauthorized' should be 401 'Unauthenticated', problem solved !

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'.

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

+----------------------- | 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)

Special case: Can be used instead of 404 to avoid revealing presence or non-presence of resource

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,

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.

User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur multiple times.

Next, let’s say that your ticket is correct (so you made through security just fine!) and the gate number in your ticket says “Gate 24” but you walk to Gate 27. The attendant cannot authorize you to go through that gate because it’s not the right gate for your ticket.

In other words, an “incorrect ticket” is similar to messing up your credentials: wrong username and/or password and you receive back a 403 Forbidden. Using the correct credentials but trying to access a resource that is not allowed for those credentials returns you a 401 Unauthorized.

You can also think that 403 happens before 401, despite the natural number order: you will not receive a 401 until you resolve a 403.

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.

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”. 😵

Indicates that though the request was valid, the server refuses to respond to it. Unlike the 401 status code, providing authentication will not change the outcome.

If authentication credentials were provided in the request, the server considers them insufficient to grant access.

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.

403 :forbidden

401 :unauthorized

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.

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.

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.

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.

In the spirit of mutual collaboration between the client and the API, the response must include a hint on how to obtain such authorization.

If the client request does not include any access token, demonstrating that it wasn't aware that the API is protected, the API's response should not include any other information.

APIs that simply map CRUD actions to HTTP verbs have nothing to do with Application State Transfer. You can call them Web APIs or HTTP APIs, but please don’t call them RESTful.

The key thing about the REST approach is that the server addresses the client state transitions. The state of the client is almost totally driven by the server and, for this reason, discussions on API versioning make little sense, too. All that a client should know about a RESTful interface should be the entry point. The rest should come from the interpretation of server responses.

In fact, most people believe that to build a RESTful API you can simply create an API based on URLs and HTTP verbs. This is absolutely false. This misunderstanding is going around for too long.

software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design

"links": { "deposits": "/accounts/12345/deposits", "withdrawals": "/accounts/12345/withdrawals", "transfers": "/accounts/12345/transfers", "close-requests": "/accounts/12345/close-requests" } } } The response contains these possible follow-up links: POST a deposit, withdrawal, transfer, or close request (to close the account).

The client transitions through application states by selecting from the links within a representation or by manipulating the representation in other ways afforded by its media type. In this way, RESTful interaction is driven by hypermedia, rather than out-of-band information.

The combined stuff is available to components using the page store as $page.stuff, providing a mechanism for pages to pass data 'upward' to layouts.

Code that is per-component instance should go into a second <script> tag.

import { goto } from '$app/navigation'; function routeToPage(route: string, replaceState: boolean) { goto(`/${route}`, { replaceState }) } replaceState == true will replace the route instead of adding to the browser history. So, when you click back, you will not go back to the route you came from.

For given hash, OpenStruct constructor only converts its top level keys.require 'ostruct' h = { foo: { bar: 1 } } obj = OpenStruct.new(h) obj.foo # => { bar: 1} obj.foo.bar # => NoMethodError: undefined method `bar' for {:bar=>1}:Hash

It's worth noting that an error can coexist and be returned in a successful request alongside data. This is because in GraphQL a query can have partially failed but still contain some data. In that case CombinedError will be passed to us with graphQLErrors, while data may still be set.

I just got caught out by realising I wasn't wrapping my component in a <Provider> that provides our own GraphQL client because the default context value is a urql client. I get why this is a good default out the box for getting started, but I'd love to disable that so that we can ensure all our components are wrapped with a provider that exposes our custom client.

Exchanges are bi-directional. So suppose you have the default order: [dedupExchange, cacheExchange, fetchExchange], then an operation describing the GraphQL request, which is only the intent to send a request, goes from outer to inner, or left to right. It'll reach dedup first, then cache, then fetch. This is the operation stream. The operation result stream goes the other way. fetch might emit a result, which is seen by cache, and then seen by dedup. This is a little abstract and we will need some visuals to make this an accessible concept to everyone. This is how it works because every exchange receives a stream of operations. It can then transform this stream and call forward with an altered stream (so every exchange has full control over filtering, mapping, reducing, timing of operations). Furthermore, every return value of an exchange is a stream of results. This means that the simplest exchange just forwards all operations and returns an unaltered stream of results: ({ forward }) => ops$ => forward(ops$). For your "error exchange" (which we should probably provide by default?) this means that it must come before the fetch exchange: [dedupExchange, cacheExchange, errorExchange, fetchExchange] Specifically, it won't need to alter the operations probably, but it will need to look at the results from the fetchExchange which means it must be outside fetch or come before it. Here's an example of a simple implementation of such an exchange: import { filter, pipe, tap } from 'wonka'; import { Exchange } from 'urql'; export const errorExchange: Exchange = ({ forward }) => ops$ => { return pipe( forward(ops$), tap(({ error }) => { // If the OperationResult has an error send a request to sentry if (error) { // the error is a CombinedError with networkError and graphqlErrors properties sentryFireAndForgetHere() // Whatever error reporting you have } }) ); };

It’s important to understand that an implements clause is only a check that the class can be treated as the interface type. It doesn’t change the type of the class or its methods at all. A common source of error is to assume that an implements clause will change the class type - it doesn’t!

Unfortunately, the part that deals with SOAP transformations is not free.

i implemented this myself this way:

We cannot make the above statement reactive because we touch tmpCopyAsTemplates.

All my stores also have a defaultValue property and reset method

// Without cloning this will point to the same object and they'll always be the same. // We'd basically change the object in the store without changing the store. let tmpCopyAsTemplates = deepClone($copyAsTemplates);

Same here, and I think this is not correct. The more I think about it, the more I am convinced it's a wrong mental model.

My case is that I have a component which takes an object as a prop. As the user changes the object's values, they can either Save or Cancel. So in the component I have two variables: value and valueUnsaved. It's similar to the example on my comment above. To avoid mutating the original object directly, I assign valueUnsaved as a deep clone of value. If value is changed outside of the component, valueUnsaved should be updated.

I've said it multiples times and I say it again: in Svelte stores solve all your problems and I love them so much.

updating b should update a as well. updating a will update b back again in the reactive declaration.

   $: b = a * 2;

It works if you always want b to be the value deriving from a. However in the example above, we want the value of b to be temporarily out of sync of a.

having inconsistencies when all the "subtle" conditions were met is unfriendly. it requires the user to have much deeper understanding of the nuances of the language.

I used the word "intended" behavior, because that is the behavior im looking for, but I may not be expressing it correctly in Svelte. It may not be the expected behavior of the code.

My mental model has always been that a reactive declaration like $: b = a * 2 defines b in it's entirety ("Here's my recipe for b and all the ingredients, please Svelte make b always up to date"). And outside of this declaration b is immutable.

For me there is a distinct difference between these two scripts: let a = 1; $: b = a * 2; let a = 1; let b; $: { b = a * 2 }; The first example defines a "recipe" for how to create b and b is completely defined by that declaration. Outside of that it is immutable, data flows only into a single sink. The second example declares a variable b and then uses a reactive statement to update it. But it also allows you to do with b whatever you want. If someone wants to go that route (definitely not me), they are free to do so at their own risk of ensuring consistency.

First of all, here is what I meant by updating reactive declared variable

The intention of the issue #2444 was to propagate the changes of the reactive declared variables back to its dependencies. in the context of this example, would meant, updating b should update a as well.

The intended behavior for the code snippet above is to reactively update b when a changes allows b temporarily go "out-of-sync" of a when calling update, setting b to 42 in this case, b is not always a * 2 however, if a changes again, b will be updated back to a * 2, instead of staying at 42

Explicitly defining the dependency in the reactive declarations

inputValue = updateInputValue(value);

I still cannot get over the fact that this is not mentioned in the documentation. I do not want to sound negative or unappreciative towards the work that went into this tool (because it has many awesome parts and awesome people working on it and contributing to it), but I do feel kind of let down that "basic" internal mechanics are not explained at all. You either have to find them out yourself or hope some other programmers did and wrote an article about it.

Sorry, let me rephrase. Is this how it is supposed to work? Because right now it looks like a bug. The documentation is really terribly sparse on this topic.

Interesting,... robertadamsonsmirth answered totally incorrect answer and got thumb up emoji, even tho, right here is proof, they were incorrect.

 "$; foo = bar.a" means that you expect foo to always be whatever bar.a is is not true

I'm not sure what behaviour it is that you expect. "$; foo = bar.a" means that you expect foo to always be whatever bar.a is, and "bind:value={foo}" means that you expect foo to to be whatever has been entered in the input. It can't be both!

I ended up writing a custom store that "buffers" sets for both a small time interval and ensuring only one async action is in flight (and triggering an extra round of async processing if a set was seen after the last async action was launched).

Pros & Cons

We should instead invalidate the ultimate dependencies of filtered rather than filtered itself:

You declare a reactive variable and it's dependencies ("recipe").

I don't think these are two different interests in contrast with each other. I wanna update that temporary object and when the dep changes I re-create the temporary object. Simple as that.

Svelte currently consistently gives the reactive statement priority over your checked binding.

I ran onto this issue too, causing double fetch request at each change.

Oh, I just figured out a workaround for my project, in case it helps someone. If you want the source of truth on the prop to come from the child component, then leave it undefined in the parent. Then, you can make the reactive variable have a condition on the presence of that variable. eg: <script> let prop; $: prop && console.log(prop); </script> <Child bind:prop/> Might not work for every use case but maybe that helps someone.

This has been particularly harmful when there is an http API call when val changes ... which triggers the call twice for no reason.

maybe this just comes down to general footguns with reactivity, and being aware of them as a developer.

Absolutely shockingly awful game from a company that puts out poor quality games. And furthermore, tries to sue YouTubers who don’t like their games for ‘slander’. Shocking games and shocking developers. Avoid at all costs.

Rails 5 recently shipped, and among many other new features is a new renderer that makes it easy to render fully composed views outside of your controllers.

UserMailer has gone untouched and the code remains as clear in its intent and expression as it was when it was written.

When you give an element a width of 100% in CSS, you’re basically saying “Make this element’s content area exactly equal to the explicit width of its parent — but only if its parent has an explicit width.” So, if you have a parent container that’s 400px wide, a child element given a width of 100% will also be 400px wide, and will still be subject to margins, paddings, and borders — on top of the 100% width setting.

This is just one of those things in CSS that seems easy to understand (and really, it should be), but it’s sometimes not — because of the way that percentages work in CSS.

In the "When sending message, automatically" section, uncheck "Place a copy in."

Click Done, sign in with your Google account if prompted and that's all!

The ticket which tracks issues using Gmail with Thunderbird (Bug 402793)

So if you subscribe to both Inbox and All mail you are in practise downloaded your mails twice. If you then delete a mail in inbox it doesnt go away in All mail. It just get the trash-tag. In my opinion you should never subscribe to All mail. You never need to see it. All you need to see are INBOX, TRASH, SENT and the folders YOU created in your gmail-account.

Thunderbird determines connection details (such as ports, server names, security protocols, etc.) by looking up your email provider in a database that contains connection information for all the major Internet Service Providers (ISPs). After determining the provider of your account (as specified after the "@" symbol in your email address) Thunderbird can usually provide the account details.

Google/gmail calls apps that don't support OAuth2 "less secure". But, that doesn't make them insecure. So what it means is gmail's meaning of LessSecureApp is basically anything that doesn’t use OAuth2.

When you initially logon with OAuth2, you will be redirect to Google’s sign-in page,. Once you have signed in, Google issues you a special OAuth2 token which is saved in Thunderbird and can be seen in the same place as passwords. So when you next logon to gmail, it is using that unique OAuth ID instead of password.

No longer depends on:

Thunderbird provides the ability to archive messages - that is, to move them from the default folders to archive folders without deleting the messages altogether. This makes it easy to organize archives or move them to a backup device, and keep the Inbox clean. Messages can only be archived manually, not automatically.

Mailspring isn't VC funded and doesn't need to make millions to succeed. Just a thousand paid subscriptions will make Mailspring a stable business and we have big ideas for the future of email.

Even if you didn't intentionally make any changes, please check that this setting is enabled.

If there is still a problem, try clearing Captcha again.  I acknowledge you wrote that you already did this, but you must open that page using the account that you are setting up in Thunderbird.  If you are signed into multiple Google accounts, the page will open with the primary account.  To be certain that you have used the correct account, please try again after signing out.

Cryptocurrencies are not only an apocalyptic ecological disaster

are also incredibly toxic to the open web, another ideal that Mozilla used to support

“Money corrupts; bitcoin corrupts absolutely. Disregarding all of bitcoin's shortcomings, a financial instrument that brings out the worst in people—greed—won't change the world for the better.” —https://www.cynicusrex.com/file/cryptocultscience.html.

The highest rating Pure Health Fungus Eliminator got on Amazon is 4.0/5 stars. Meanwhile, it got 4.9 stars out of 5 on its official website. I’m not saying that the higher rating is entirely biased. But I just think that we get to see more honest reviews outside its site.

I wish there's some kind of an optional ghost or something that I can follow after a while to teach me why I cannot get past a certain area.

For example, given a website's normal communication method is the internet, out-of-band communication may be by a voice call.

Out-of-band communication may even be by beeps from the PC speaker on the server's Motherboard.

Your character feels nigh impossible to control - you move very very fast, but if youre in the air, you dont stop moving the moment you stop holding a direction, so you have to constantly cancel out your momentum to stop, but if you dont do it perfectly you suddenly fly in the other direction

TLDR: Amateur and poorly executed "Qix" type arcade game. Play Lightfish instead. It uses the same core concept but executes much better.http://store.steampowered.com/app/116120/Lightfish/E

I bought this game in order to review it, seeing as there were no current reviews for it. I thought I'd help the game out by maybe giving it that tiny bit of publicity it needed to get off the ground.

This is the kind of game that, if the quality was better, I might give it a maybe, if Steam offered one.

A good riddance from the ultra realistic modern 2021 games . Or maybe its my personal opinion that most games towards the better side should be like 16-bit only. It certainly took me back to the era of Nintendo when I frankly used to enjoy gaming the most. The look and feel of Tobe's quite resonates with good old konami games, Contra, adventure island, Super Mario, Circus Charlie, Dangerous Dave.

Hardcorps

It seems like it could be a good game but its really poorly executed,

Unique concept that could have end up as a great game, but sadly got destroyed by lack of polish .

A plumber was a man who used lead for many reasons. Since lead was very malleable and had a low melting temperature it was employed quite a great deal to seal and repair.Pipes used to be connected and secured just as they are at present, although now we use plastics or ceramics.

One may think that the pipes leading to the sink, and the job of installing or maintaining them is described as plumbing since pipes were previously made with lead and the Latin word for lead was plumbum (consequently the elemental letters Pb).While this fact is absolutely valid, it is additionally true that plumbers were once employed in additional ways than installing pipes when the phrase plumber originally became popular in French then English within a century around the 14th Century A.D.

Furthermore, lead is very weighty and so it was often used in the role of a weight. At the end of a twine hung to be certain of a perpendicular line it is described as a plumb bob. Persons in charge of water workings earlier than the era of dependable pressure systems had to fall back on on gravity defined methods and so accurate lines and levels were essential.

.pgpass does not define a default database. It only provides the passwords for a combination of hostname, database and username.

But he has a special ability - TIME SLOWS DOWN WHEN HE MOVES.

The diagram raises an interesting question which you may not have thought about before. How does all the information from the internet get to the right device inside the network? If you visit howtogeek.com on your laptop how does it end up on your laptop and not your son’s desktop if the public-facing IP address is the same for all devices? Advertisement pagespeed.lazyLoadImages.overrideAttributeFunctions();tmntag.cmd.push(function(){tmntag.adTag('purch_Y_C_0_1', false);}); This is thanks to a wonderful bit of routing magic known as a Network Address Translation (NAT).

the whole language is a shame, but it's so useful :)

If you're using bash, you don't need to use sed to do string replacements (and it's much cleaner to use the replace feature built into bash).

We tag and release gems according to the Semantic Versioning principle. As a result of this policy, you can (and should) specify a dependency on this gem using the Pessimistic Version Constraint with two digits of precision.

Nested contexts tags are overwritten not merged: TestProf::LetItBe.configure do |config| config.default_modifiers[:freeze] = false end context "with reload", let_it_be_modifiers: {reload: true} do # uses freeze: false, reload: true here context "with freeze", let_it_be_modifiers: {freeze: true} do # uses only freeze: true (reload: true is overwritten by new metadata) end end

config.define_derived_metadata(let_it_be_frost: true) do |metadata| metadata[:let_it_be_modifiers] ||= {freeze: true} end

Thus it's not easy to refactor existing tests which use let/let! instead.

It's well-suited for dev/test since it doesn't need an external infrastructure, but it's a poor fit for production since it drops pending jobs on restart.

declaration accepts: | null | [] | [null] | [{foo: 'BAR'}] ------------------------------------------------------------------------ [Vote!]! | no | yes | no | yes [Vote]! | no | yes | yes | yes [Vote!] | yes | yes | no | yes [Vote] | yes | yes | yes | yes

[Vote!]! means that the field (in this case votes) cannot return null and that it must resolve to an array and that none of the individuals items inside that array can be null. So [] and [{}] and [{foo: 'BAR'}] would all be valid (assuming foo is non-null). However, the following would throw: [{foo: 'BAR'}, null] [Vote]! means that the field cannot return null, but any individual item in the returned list can be null. [Vote!] means that the entire field can be null, but if it does return a value, it needs to an array and each item in that array cannot be null. [Vote] means that the entire field can be null, but if it does return a value, it needs to an array. However, any member of the array may also be null.

I could look into this more to understand where things are going wrong, if you can suggest to me which part of the way this is working might be off.

Besides that configuration, SvelteKit is just a normal Vite project that does rendering on both SSR and client-side.

Two wrongs don't make a right We should fix it in popper core. I sent a PR there: floating-ui/floating-ui#1342

Just import it the normal way. Then Vite can use the CJS version on the server-side and ESM version on the client-side. Forcing it to always be ESM breaks SSR with the latest SvelteKit.

The code isn't going back to the way it was So otherwise you'll be stuck on an old version forever...

Deeply importing Svelte components is not supported. Either import all components from one entrypoint, or always stick to deep imports, otherwise it could cause multiple instance of the Svelte library running.