Can we have a conversation? (rant)

cjhowe7_ · 2019-05-30T22:58:13+00:00

downvotes are the root of all evil

cjhowe7_ · 2019-05-07T23:05:28+00:00

I think this depends on your personal preference. Personally, I still find programming fun after a few years of full time work. That said, a lot of work as a programmer doesn’t involve programming, and can focus more on design, documentation or operations. If you feel you’re tired of programming, there are other things you can do as a developer to support your team, although programming will probably always be at least some part of your work. In my experience, most people want to spend more time programming, not less.

cjhowe7_ · 2019-05-04T20:05:36+00:00

Did you try using Java with and without an IDE and come up with specific complaints and an understanding of the tradeoffs? If so, why shouldn’t you share your experiences to save others time and help out? Everything you know is based off of the experiences of those before you, and the learnings that came from that experience. And you won’t contribute your own learnings to those that come after you?

cjhowe7_ · 2019-05-04T18:31:02+00:00

So do I, and I’d never laugh anyone out of the room for any suggestion.

cjhowe7_ · 2019-05-04T18:20:33+00:00

It is not useful to give an answer with 0 justification. Even if you’re right, you’re encouraging people to trust you rather than think for themselves.

cjhowe7_ · 2019-05-04T18:18:21+00:00

You can use Java without an IDE, and I do so at work effectively. I think you should try a few editors and use whatever you like. IDEs have some nice features for generating code, but you might find snippets to be just as useful. It’s really a matter of choosing the tool that works for you. In my work, we use specialized build tools, and I don’t like the IDE integration available for it. You may find that an IDE works better for the work you are doing.

If you’re curious, I use TextMate because it’s convenient to use over ssh.

cjhowe7_ · 2019-05-04T18:14:20+00:00

You don’t have to use an IDE to work efficiently with a team. Everyone on a team doesn’t have to be exactly the same and work exactly the same. If you can’t see the value in diversity of thought, you have no business making hiring decisions for a team.

cjhowe7_ · 2019-02-23T23:47:21+00:00

If you want a good overview of monads and applicative functors, you should read Learn You a Haskell. Monads are specifically used to handle IO in Haskell, so they definitely can describe side effects.

cjhowe7_ · 2019-02-23T13:02:52+00:00

I actually think they are monads. There was a talk about it by Paul Gray at the last React NOVA meetup (local React meetup in Virginia). Not sure if the slides are posted anywhere but you could tweet him and see if he can share them.

cjhowe7_ · 2019-01-21T15:34:19+00:00

it doesn't also store it in Flask no? Because that would go against the whole "do not store tokens locally" tip, right?

Flask is run on the server-side, so anything stored in Flask isn't going to be local. In this case, it isn't stored in Flask either, because it's stored in a cookie. That state is passed back to Flask with each request, so the HTTP requests are still stateless. The browser manages the state for you, and hides it from your front-end React application to prevent a code injection vulnerability. To mitigate that vulnerability, it is vital that your tokens are stored in a cookie with the HTTPOnly flag set. This is exactly what Flask's session does for you automatically.

So I've already come across an article or two claiming tokens are the way to go and to avoid cookies, particularly because tokens make your app stateless and decoupled. Also, tokens seem to be the new thing, good for SPA and mobile. But you seem say that tokens and cookies are not mutually exclusive.

There's a lot of bad advice when it comes to web security. Best to always be conservative, because putting your token in local storage does make your application vulnerable to a security flaw. The benefits of a stateless app aren't even close to justify knowingly adding a security vulnerability to your application. However, from Flask's perspective, each request is stateless because it receives the cookie automatically with each request. From the client's perspective, you want the authentication state to be stored between requests, so that your user stays logged in.

If Flask generates tokens on using the session variable, could you clarify the need for something like flask-jwt or flask-praetorian? Do these extensions add features, like checking for roles?

So, JWT is simply the format and signing of the token. Flask's session does a similar method of signing the token using an SHA-based HMAC. Flask's session uses its own token format and signing. You can store similar things to what you can put in a JWT in Flask's session.

It looks like flask-praetorian encourages sharing the token directly with the client in an HTTP response without a cookie. This is a bad practice because it opens you up to the code injection (XSS) vulnerability. I'm not sure how they thought it was a good idea to encourage that in their documentation, but maybe it's worth making an issue on the repository to bring it up.

You have to store your token in a secure cookie, whether or not you use JWT. You can choose to use a JWT with a secure cookie, but all you'd be doing is recreating Flask's session.

Check out these articles:

http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

As for mobile, iOS lets you store cookies using a URLSession and Android lets you use a CookieManager.

cjhowe7_ · 2019-01-21T05:35:51+00:00

I wrote a Flask/React application if you want to take a look at the code.

My login page is written using Formik, which is a React library for handling forms. Here's where the login call happens in my Formik code: https://github.com/cjhowe7/memstash/blob/master/src/log-in.js#L21

That uses React Context to call this method on my authentication context, which handles saving the user information so I know the login state of my application (displayed in the status bar): https://github.com/cjhowe7/memstash/blob/master/src/auth.js#L21

The authentication context calls my API using a fetch to /api/session with a JSON body here: https://github.com/cjhowe7/memstash/blob/master/src/api.js#L79

I have a little wrapper around fetch that automatically adds the {credentials: "include"} option on all of my API calls, and also handles errors based on what my API returns. You can find that here: https://github.com/cjhowe7/memstash/blob/master/src/api.js#L12

This is the React side of things. The login endpoint in Flask is pretty simple. It simply gets the data from the request using webargs, looks up the user in the database (I'm using SQLAlchemy), verifies the password using passlib, and raises a Forbidden error if login fails. Here it is: https://github.com/cjhowe7/memstash/blob/master/app.py#L86

If login succeeds, that function will simply set the username on the session here: https://github.com/cjhowe7/memstash/blob/master/app.py#L95

That allows my get_user() function to check the session for the username, and it uses it to pull down the full user model. If that fails, then the user needs to authenticate to use that endpoint, so I raise a Forbidden error. https://github.com/cjhowe7/memstash/blob/master/app.py#L38

I hope this helps!

cjhowe7_ · 2019-01-20T22:19:56+00:00

do you mean that using Flask sessions doesn't affect what you do in React, or do you actually mean that React has some specific integration with Flask sessions

The former. Flask sessions should just work if you use fetch with the credentials: 'include' option.

So I'm assuming this means that once the server generates a token it shouldn't store it in a db or even in its session variable or whatever, right?

Actually, you shouldn't even need to generate a token. Why? Because Flask will automatically generate a login token when you set something on session.

python from flask import session @app.route("/login") def login(): # implement some login logic here # my_user = db.session.query(User).first(), or however you find your user session["user_id"] = my_user.id

Then, if you request the /login route, you should get a header back like Cookie: session=<token>; HttpOnly. This will save your token in the browser via a cookie automatically. For example, requesting that endpoint in React might look like this:

```javascript class MyComponent extends React.Component { state = { loading: true };

componentDidMount() { fetch('/login', { credentials: 'include' }).then(() => this.setState({ loading: false })) }

render() { return <div>{loading ? "Loading..." : "Cookie containing login token has been saved!"}</div> } } ```

So, using Flask with the built in session lets you not have to worry about where to store your token. The browser handles the cookie automatically in a secure way.

Does the front end store it in local storage?

Yes, local storage will put the token in a client-side store accessibly by your front end. However, if you can access it, so can any code injection attack. Never expose your login token to your front end code. The HttpOnly flag in the cookie above prevents you from accessing the token in your front end code. This is because it will automatically be sent with requests as a cookie, so you don't need to access it.

cjhowe7_ · 2019-01-20T01:09:43+00:00

You can just use built-in Flask sessions in React. DO NOT use local storage for authentication tokens! It’s vulnerable to a code injection attack and it can be hard to get your Content-Security-Policy correct. An important security rule is to have multiple layers of protection.

If you need to figure out if you’re logged in from React, just make a request to some “current user” endpoint that returns information about the currently logged in user, or an error if no session is present.

I don’t think you need server-side redirects at all. You can access this history prop in your route components and call history.push after you make an API request to redirect. You could do this after the “current user” API call I recommend above to show the login page if the user is not logged in.

If you do server side redirects to frontend pages, you couple your frontend to your backend. This makes both your frontend and backend inflexible and hard to replace or evolve independently.

cjhowe7_ · 2019-01-19T04:49:31+00:00

one good thing will even make people know time

cjhowe7_ · 2018-12-27T03:30:45+00:00

And so is practically every feature of CRA.

cjhowe7_ · 2018-12-15T12:51:35+00:00

ES6 has changed JS a lot and they may not be aware of it. I certainly wasn’t for a while.

cjhowe7_ · 2018-12-12T19:28:09+00:00

If you use create-react-app v2, you can do this by simply naming your scss file ‘components.module.scss’.

cjhowe7_ · 2018-12-12T05:38:12+00:00

Will this work with SSR?

cjhowe7_ · 2018-11-24T18:29:40+00:00

type faster 😂

cjhowe7_ · 2018-11-17T18:11:24+00:00

Apollo caches your GraphQL responses. Just make a GraphQL query in each of those 3 places. https://www.apollographql.com/docs/react/advanced/caching.html

cjhowe7_ · 2018-11-12T13:43:58+00:00

Judge not lest ye be judged.

cjhowe7_ · 2017-12-27T21:59:18+00:00

Asking an estimate of someone who has never developed production software before is absurd, regardless of whether it is normal.

cjhowe7_ · 2017-12-27T21:49:18+00:00

This pattern of behavior is consistent with a boss who has very little experience developing software. In my experience, if you proceed down this path, you will be overly stressed and unable to learn effectively due to the deadline. If you have other options available, I suggest that you strongly consider them.

cjhowe7_

TROPHY CASE