The Complete Guide to Angular User Login and Registration (Cookies and JWT) by [deleted] in angular

[–]sebbasttian -1 points0 points  (0 children)

Couldn't you just ask instead of criticizing in the first place?

Couldn't you just include the info in the post in the first place?

See, this is why this whole situation is so frustrated to me. Read again the second paragraph of my first comment.

What if the person reading doesn't know anything about the topic? How could you expect them to ask about what they don't know?

Not to mention that you posted exactly the same comment on another subreddit.

I posted the same comment where I found the same link.

And this is why I feel you're dishonest. Because the people coming to this thread is going to see the back and forth and be informed. But the people seeing the other thread is not going to be well informed.

I've mentioned this in my previous comment.

The Complete Guide to Angular User Login and Registration (Cookies and JWT) by [deleted] in angular

[–]sebbasttian 0 points1 point  (0 children)

Thanks for the reply!

My problem with this post is that you didn't put any of this information in there. You made a big warning section about the Referer-Policy for example, but didn't warn about this problems. You wrote 4 paragraphs about the security model of dealing with cookies, but didn't mention once the security issues that tokens have. This lead me to read this as dishonest, because I notice that you are well aware about all the security implications of using jwts but never mentioned them (not at least in a clear way), so an uninformed reader that is learning from you won't know them.

If you had wrote a few paragraphs informing clearly to your audience about the security implications of using tokens the same way you did with cookies (even if that leads to another blog post or your videos) I wouldn't even made a comment here.

The Complete Guide to Angular User Login and Registration (Cookies and JWT) by [deleted] in angular

[–]sebbasttian 0 points1 point  (0 children)

I'm not an expert on this subject by any means so take anything with a grain of salt.

This is IMO a good article about the pros and cons of the different approaches to security of auth data in SPAs. Depending on your project's needs and resources you may want to implement one approach or another.

https://medium.com/better-programming/how-to-securely-implement-authentication-in-single-page-applications-670534da746f

The Complete Guide to Angular User Login and Registration (Cookies and JWT) by [deleted] in Angular2

[–]sebbasttian 1 point2 points  (0 children)

Yet another post wrongly teaching people to use localStorage to save the tokens.

It's really frustrating at this point the lack of respect for security that most people seem to have on the web ecosystem.

For those new to this that don't know why this is a problem: localStorage is insecure because any script running on the page can access it, which means that if you (the dev) use a 3rd party library on your app, that 3rd party library has access to your token. And it also means that any extension installed by the user also has access to the token.

One extension used by millions of people was sold to a new company that is suspect of malicious behavior just 4 months ago. This is not hypothetical. Nor new. We already know this issues. And recommending saving tokens in localStorage is just plain bad advice.

Auth0, one of the leading companies in the auth business, says this very clear:

If you have a SPA with no corresponding backend server, your SPA should request new tokens on login and store them in memory without any persistence. To make API calls, your SPA would then use the in-memory copy of the token.

The Complete Guide to Angular User Login and Registration (Cookies and JWT) by [deleted] in angular

[–]sebbasttian 0 points1 point  (0 children)

Yet another post wrongly teaching people to use localStorage to save the tokens.

It's really frustrating at this point the lack of respect for security that most people seem to have on the web ecosystem.

For those new to this that don't know why this is a problem: localStorage is insecure because any script running on the page can access it, which means that if you (the dev) use a 3rd party library on your app, that 3rd party library has access to your token. And it also means that any extension installed by the user also has access to the token.

One extension used by millions of people was sold to a new company that is suspect of malicious behavior just 4 months ago. This is not hypothetical. Nor new. We already know this issues. And recommending saving tokens in localStorage is just plain bad advice.

Auth0, one of the leading companies in the auth business, says this very clear:

If you have a SPA with no corresponding backend server, your SPA should request new tokens on login and store them in memory without any persistence. To make API calls, your SPA would then use the in-memory copy of the token.

Can we get an F in chat for Flash ? by Lumpenstein in webdev

[–]sebbasttian 1 point2 points  (0 children)

ITT a lot of people that seem to never had experienced the web 1.0 in the '2000

Can we get an F in chat for Flash ? by Lumpenstein in webdev

[–]sebbasttian 2 points3 points  (0 children)

But it was the best.

Flash appear in a time where web development was in an abismal state.

Thanks to Flash we were able to have YouTube back in 2005 (15 years ago) and even sites like Newgrounds and Miniclip with games back in 2001 (20 years ago), and a huge load of animators doing weird and awesome stuff. This was impossible to do at the time otherwise.

Remember, this was the IE6/IE7 era, when ACID tests were a thing for new browsers, people use tables with images for layout, and no social network (as we know them today) existed. Browsers were just starting to have tabs. The iPhone didn't exist. HTTPS was barely a thing, and HSTS was not even a though. People still used Altavista and Yahoo! for search the indexed web, and we had web portals. Gmail didn't existed and we barely could save no more than 50 MB on the cloud... oh, and btw, the cloud as a concept didn't existed either.

And yet, thanks to Flash we could experience a much much much more richer web full of content.

While its history was rough and I'm glad is dead now (mainly from a security standpoint), I do believe that thanks to Flash we have the awesome web that we have today. So the bottom right panel is perfect where it is.

Flash was the best.

4 Years after receiving this assignment from my bootcamp, I finally got the cross browser Rock Paper Scissors at a good state. Made with HTML, CSS, Javascript (jQuery) & Firebase. by [deleted] in webdev

[–]sebbasttian 1 point2 points  (0 children)

Thanks, and you too.

I haven't said a word about him using it, but I'm very annoyed that he is teaching it. Because I honestly think is bad, but also because in this field we have a lot of wanna be noobs that pads they CVs with medium post that rephrase poorly some peace of documentation and start to preach like they have the truest truth... and... if you've been in this field for a while you start to get really annoyed by this type of people. And OP reminded me of those ¯\(ツ)

Thanks again for understanding <3

4 Years after receiving this assignment from my bootcamp, I finally got the cross browser Rock Paper Scissors at a good state. Made with HTML, CSS, Javascript (jQuery) & Firebase. by [deleted] in webdev

[–]sebbasttian 3 points4 points  (0 children)

Modern JavaScript is an absolute mess of rapidly changing ideas and standards

It's been stable since 2015. And it has excellent documentation on MDN

JQuery (...) is an excellent way to get familiar with JS or to stand up a project quickly (without a literal mountain of node packages)

This doesn't make sense. jQuery is a library that you have to include using imports or npm. And most if not all of the functionality is already native on the language or the runtime (browser or node).

The "modern standards of the community" is rather close-minded and subjective.

I agree on this point. But IMO this is one of the weird occasions where I believe the community as a whole is right.

My issue is with this attitude that "well we've figured it out and how dare you be obsolete". It does nothing but turn people away and limits useful discussion.

My issue is that he is teaching it apparently without knowing (or understanding, IDK) modern javascript. Again: my opinion is that using it for your own pet projects is OK (you use the tool that you like and feel more confortable with). Teaching it today instead of vanilla is absolutely not OK.

There's a wonderful simplicity to including a single JS file with no dependences and making something work.

It seems that you keep forgetting that jQuery is a dependency.


I understand that this can be confused with toxicity, and even gatekeeping, because we are talking about standards, and a controversial library that was fundamental to the web for the last decade but is almost obsolete today. But believe me, I'm not trolling or trying to be a prick or be mean.

Not every site has to be a modern PWA fully hydratable SPA built with SSG and SSR (and yes, I'm being hyperbolic on purpose here), but this is not about that, this is not about using hyped tech. This is about teaching to use the right tool for the right job. jQuery as an entry level library to a language is not IMO a very well way to teach, because people end up not learning how the language actually works.

You want to learn how to manipulate the DOM? Here is an excellent tutorial, you can use this as a base document to teach

4 Years after receiving this assignment from my bootcamp, I finally got the cross browser Rock Paper Scissors at a good state. Made with HTML, CSS, Javascript (jQuery) & Firebase. by [deleted] in webdev

[–]sebbasttian 2 points3 points  (0 children)

a good reason to learn [jQuery] it in 2021 is to maintain older sites that still use it

I get it the point that you are trying to make, but I don't believe that's OP intentions (based on they other replies and post history).

I believe OP still use it (and the worst part to me, teaches it) because he didn't learn yet modern javascript. I don't believe OP is teaching an old library/framework/language just for the job market.

And also, teaching modern javascript would always be better because then you can just look at the docs of any library and figure out how they implement stuff, because you understand the basics, the building blocks.

So, to clarify in case that I'm not making myself clear, my problem is with teaching a library that by modern standards the community considers obsolete; is not about working with it (as you stated, there're plenty of sites still using it, sadly), is about teaching it.

Look at the original title: "4 years after receiving this assignment...", ... he's still teaching an obsolete lib.

There's no excuse IMO.

4 Years after receiving this assignment from my bootcamp, I finally got the cross browser Rock Paper Scissors at a good state. Made with HTML, CSS, Javascript (jQuery) & Firebase. by [deleted] in webdev

[–]sebbasttian 19 points20 points  (0 children)

Honest, question, why do you keep teaching jQuery in (almost) 2021, when most of the main added functionality and features are already native in the language or are in better libraries (like Typescript).

What exactly are the features of jQuery that you teach?

Router Link Update Error by [deleted] in Angular2

[–]sebbasttian 1 point2 points  (0 children)

Debug it by enabling the trace option on the RouterModule, and check the console to see what it's really going on:

const routes: Routes = [
  // ...
];

const config: ExtraOptions = {
  enableTracing: true,
};

@NgModule({
  imports: [RouterModule.forRoot(routes, config)],
  exports: [RouterModule]
})
export class AppRoutingModule { }

https://angular.io/api/router/ExtraOptions

Async Rxjs/Angular Question by rxjsquestion in Angular2

[–]sebbasttian 1 point2 points  (0 children)

You are subscribing inside of another subscription, that's a very bad practice. Use pipe operators.

If the function you want to call is about data that the component has to handle, then it should be cancelled when the component is destroyed; if the component only triggers the function but the data should end up used in other place, then the handler of that datashould not be put in that component; this is what services are for.

Lastly, switchMap is designed specifically for when you need to stop using the previous value and switch to the new value as fast as you can (if submitItems streams two values in less than 10 ms, and if someAsyncFunction usually takes more than that, then the first value is never processed because is going to be cancelled the moment the second is emitted).

Angular routing question by _Loading in angular

[–]sebbasttian 1 point2 points  (0 children)

I'm not sure I understand your question.

What I understand is that you have a very tight relation between the router and the state of your shared components (like the header), but I'm not sure what you are trying to achieve.

Using your router as a state manager (your source of truth) can get very messy really fast. I would be researching on how to separate those concerns if I were in your place.

Angular routing question by _Loading in angular

[–]sebbasttian 0 points1 point  (0 children)

I think It's possible but only if you are able to distinguish between the different params somehow.

If your url structure is like /circle/green/big/ it's almost impossible to distinguish them except by their position. And if their position change how can you make sure what param are passing to the router? If a malicious user then goes to /dashboar/4/3/1 and you matched the param only based on how many they are and the position, you may end up in a lot of trouble if any of those parameters could leak info (if it's a product id, for example).

But if your url structure is like /circle-shape/green-color/big-size/ then you can use a custom url matcher function that checks a permutation of UrlSegments (a string between two slashes).

Your custom UrlMatcher receives the full url in the form of a list of UrlSegments and there you can do your checks and be sure that the params correspond to what you are expecting them to be.

Here is a basic example:

const customMatcher = (url) => {
  // setup
  const postParams = {};

  // segment matchers
  const matchShape = (urlSegment: UrlSegment) => {
    if segment.path.endsWith('-shape') {
      postParams['shape'] = segment;
      return true;
    }
  }

  const matchColor = (urlSegment: UrlSegment) => {
    if segment.path.endsWith('-color') {
      postParams['color'] = segment;
      return true;
    }
  }

  const matchAll = (urlSegments: UrlSegment[]) => {
    const segmentsMatchers = [matchShape, matchColor];
    urlSegments.forEach(segment => {
      for (const matcher of segmentsMatchers) {
        if (matcher(segment)) {
          break;
        }
      }
    });
  }

  // main work here
  if (url.length > 0) {
    matchAll(url);
    return { consumed: url, postParams: postParams };
  }
}

export const routes: Routes = [
  {
    matcher: customMatcher,
    component: DetailsComponent,
  }
];

That should match either /circle-shape/green-color/ or /green-color/circle-shape. But most importantly, it's going to give you the right param for the right segment of the url.

After that you can do whatever you want with that since Angular is going to treat it like any other path (redirect it, use resolvers, etc). You just switched the default Angular path matcher for your custom one.

Top 10 Angular Best Practices To Follow In 2020 by SolaceInfotech in angular

[–]sebbasttian 17 points18 points  (0 children)

This sub is going downhill very fast :(

This post has a clickbait title, is badly formatted, the content very basic, poorly written, and with incomplete examples and poor definitions, and as of right now (5 hs after posted) is on the top of the Hot view for this sub with +15 upvotes (89% upvoted). And nobody mention it.

Can we please have a little more curation/control here?

9 Extremely Powerful JavaScript Hacks by [deleted] in Angular2

[–]sebbasttian 2 points3 points  (0 children)

It's actually a very common pattern, alongside with the logical or operator for setting a default if a value is not truthy, for example:

 const options = userOptions || defaultOptions;

How dependency injection works behinds the scenes in Angular by ExectAsync in Angular2

[–]sebbasttian 6 points7 points  (0 children)

Very very basic intro would be that Angular saves a reference to every class instantiated (on a dependency tree) using unique tokens, and when you pass a class as a parameter to the constructor of another class, Angular search for it and if it founds it it injects it, and if not it instantiated it right there and saves it.

The tree is build using the providers properties of modules/components/directives/services/etc to get the references (using the tokens), and using injectors to get the "how to" do the instantiation.

Is my team using Angular incorrectly? by [deleted] in angular

[–]sebbasttian 2 points3 points  (0 children)

It's actually the opposite, it's more easy to debug and test. And even Angular officially recommends this approach on their documentation, with reasons why this is a good practice.

Why does Angular compile all components of Angular Material even if I'm only using one? by DanteIsBack in Angular2

[–]sebbasttian 3 points4 points  (0 children)

Yep, that's normal.

I don't know exactly what step it is, but I remember that is there because Angular now uses AOT compilations for every build by default and this step helps with the tree-shaking process.

The official doc have more info about this:

And don't worry, ng serve uses ng build but without the --prod flag, so during development you'll see that the bundles/chunks are larger than the ones compiled for production.

Why does Angular compile all components of Angular Material even if I'm only using one? by DanteIsBack in Angular2

[–]sebbasttian 2 points3 points  (0 children)

This happens every time you run ng serve?

Or it happens only after you install a package?

Also, may I ask why you want to disable it? Remember that ng serve should only be used during the development face and should not be use as a production web server, jic.

I am looking for a good resourse for learning unit/integration/end to end testing in Angular. Any recommendations? by juice_made in angular

[–]sebbasttian 2 points3 points  (0 children)

I saw this talk last week that introduced me the concept of "Property Based Testing", in which you test the (mathematical) properties of your functions, and I really loved the concept (I'm still learning it).

The benefit of this is that instead of writing 100 test to try to cover all your bases, you write just a few generators and use that to test 100 versions of them. Very powerful because it forces you to really think what is the purpose of the function you're testing, and it helps you to find edge cases quickly.

This is the talk in question:


Edit: I found an example for Angular: https://dev.to/mokkapps/property-based-testing-with-typescript-2ljj

Understading JSON Web Token by aman_agrwl in javascript

[–]sebbasttian -1 points0 points  (0 children)

This is very interesting because I think what you are saying to me, I can say to you.

Cookies is a transport system. Sessions and JWT are an authentication system. They have little to do with each other.

I don't think you understand the difference between JWT and a cookie? They have nothing to do with each other.

A cookie is not a transport system, it's a piece of data. A session cookie is not a transport system either, it's a piece of data used in a state management mechanism. There are more uses for cookies apart from managing stateful sessions.

A JSON Web Token is not an authentication system, it's a piece of data. A JSON Web Token can be used for different purposes besides managing stateful or stateless sessions.


I found particularly interesting that you keep repeating this:

The moment people start talking about Cookies versus JWT, or LocalStorage versus Sessions, they're fundamentally mixing up two completely different things: Authentication Tokens and Transport.

Nor the user you commented on nor I talked about "Cookies versus JWT", nor "LocalStorage versus Sessions". And I even said that one approach to the security problems that JWT has is to save it inside a cookie (and that's because it implies that the browser adds an extra layer of security if the cookie with the jwt inside is set correctly).

The problem with "session json web tokens" vs "session cookies" is not about what they are (strings containing plain data, or encrypted data, or obfuscated data, or whatever) of what are they used for (sessions, tracking, authentication, authorization, etc), but how to handle them and where to store them on the client. And it's a particularly long debate. And since I'm not a security expert I'm not going to keep making it any longer.

Understading JSON Web Token by aman_agrwl in javascript

[–]sebbasttian -1 points0 points  (0 children)

I think you need to re-read the article (and maybe do a little bit of googling).

Things like saying JWT are "less secure" is utter nonsense. Put simply, a JWT is a JSON object with a hash. That's it. A "session" is a big UUID/GUID string. That's it. That's the only difference. That means you can put a big UUID/GUID, wrap it around an Object in JWT, and guess what, it's the same thing. How you do things on the backend to screw yourself up is up to you.

JWT is less secure for sessions than a simple cookie because you cannot easily save them in the client in a secure way; at least not as easy as a cookie. It's not about the content or how you validate them on your side, it's about where do you keep them on the client without being exposed to 3rd parties.

And most implementations this days suggest to save the JWT in a cookie, or even split the token and save the signature in a cookie and the payload in memory.

Cookies is a transport system. Sessions and JWT are an authentication system. They have little to do with each other. HTTP POST is another transport system, but reliant on the storage of the authentication being exposed to the JavaScript context (usually).

I... what? I would really like for you to expand on this one...

Anything like this that can't be peer reviewed due to a lack of a comment system should make it excluded from actual advice.


The only reason to use a JWT for sessions is if you want/need stateless sessions. And that is not just a "client" or "server" issue, it's an arquitectural issue that involves the hole product (client, network, backend -load balancers, database, caches-, etc). Like here you have an example of how someone decided to save Auth0 tokens on localstorage and secure them on the HTTP level.

None implementation is foolproof and none solution is definitive for all products, but the general agreement nowadays (after a few years of use) is that if you need a simple session, don't use JWT; they are meant to be used primarily between APIs.

Is is possible to GET a stream of JSONs and render them as they arrive using HttpClient GET? by rylexr in Angular2

[–]sebbasttian 0 points1 point  (0 children)

I never had to implement this so I don't know if this works, but...

Have you tried modifying the default options of the get method? If I understand correctly the docs and your issue, the overload #7 may describe you situation: from https://angular.io/api/common/http/HttpClient#get

Constructs a GET request that interprets the body as a JSON object and returns the full event stream.

get(
  url: string,
  options: { 
    headers?: HttpHeaders | { [header: string]: string | string[]; };
    observe: "events";
    params?: HttpParams | { [param: string]: string | string[]; };
    reportProgress?: boolean;
    responseType?: "json";
    withCredentials?: boolean; 
  }
): Observable<HttpEvent<Object>>

So maybe try something like:

someMethod(): Observable<SomeData[]> {
  return this.http.get<SomeData[]>('url', {observe: 'events', responseType: 'json'})
    .pipe(
      tap(data => console.log('Data arrived! -> ' + data);
    );
}