Hacker News new | past | comments | ask | show | jobs | submit | cwales95's comments login

I’m similar but have three main editors:

Vim for super quick changes (I’d like to increase my proficiency with vim but not really done much to do so).

Vscode for light text editing : coding which doesn’t require me to dig in to debug for a major length of time.

Jetbrains IDE for real work / tinkering were I may need to debug / leverage breakpoints / have good autocomplete.


I think this is a great resource but wish it had not chosen a hybrid architecture. All the guides on decoupled Django seem to choose hybrid. It makes sense because you get the CSRF / XSS safety benefits but I'd love to see how others tackle a fully decoupled Django stack e.g. oAuth, JWTs and how they do their CSRF / XSS security. It's an area I need to learn more about.


Decoupled Django usually means that you are providing a client SPA with a API, such as a DRF powered REST API.

If you are using something like token auth (you mentioned JWT), then you are not using cookies, at which point CSRF is not needed. This is because the user's browser isn't automatically sending the cooking containing a session ID on every request to the server.

That said, you can implement session auth with DRF REST APIs, which accept a session cookie on requests. For this, I believe you would receive/send CSRF tokens via HTTP headers.

XSS is not something you would worry too much about in an API endpoint. It is something you should worry a lot about in your client side SPA though. If using something like React, your templates will be auto-escaped, and thus you have to go out of your way to make it a problem.


Where I get confused is storing the tokens securely. There's a lot of conflicting information online. I've come across many examples where they suggest localStorage which is a horrible idea.

A lot of the advice I see now is about http-only cookies but I think I'd probably look more into oAuth in the future.


The current best practice is to keep the token in memory only and store a refresh token in an HTTP-only cookie.

In my experience though, if you’re only doing web-based auth and don’t _need_ to use JWTs for a specific reason, just use regular session cookies, it’s way less hassle. Coordinating auth and refresh state across page refreshes and tabs is a pain, and using a refresh token means you’re using cookies and saved session state anyway, so you lose pretty much all of the unique benefits of using JWTs and still have all the downsides.


> All the guides on decoupled Django seem to choose hybrid

For someone ignorant (me), can you expand on what you mean by "Decoupled Django" and "hybrid"?



I'm similar but I tend to use spotlight for launching. I do sometimes use the dock but all animations are disabled and it's hidden by default.


AI written content should really be banned. I don't want to read content from a bot I want to read content from a human.


Whenever I obtain a 'smart' TV, I never connect it to the internet. I don't want a TV that can phone home.


Looks good.

I recently just created my own custom new tab extension. Closed source because it's literally just for me. It does a few nieche things e.g. syncing a todo list that also appears on a e-ink display. I like it. I also like that it's something that's just for me.


I actual wrote a similar post a while back: https://www.chriswales.uk/blog/my-favourite-macos-terminal-c...

networksetup was one of my favourites as well as du and caffeinate.

The 'security' command is new to me so thanks!


This was my opinion. Saying it's either blue or green when it looks to be a bit of both didn't sit well with me.


No one company can be.


I think that this is spot on. Microsoft can't be trusted with open source... and nor can any other company. The exact logic that the author of this piece (correctly) uses to scrutinize Microsoft also applies to every other business. As soon as the right/wrong person gets sway in the company, the companies will be only too happy to burn their reputation for a short term profit.

I wish that it were simply a Microsoft problem, because that would be easy. Don't do business with them (or build open source efforts around them) and you would be good. But unfortunately, bad actors abound and they will screw you if they get the chance. So you have to make sure no one organization gets the power to cripple you, no matter who it is.


Yeah, cannot help but agree. It should have been impossible for this to happen in the first place.


> It should have been impossible for this to happen in the first place.

Exactly, CEO should have fired himself for allowing that environment to exist.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: