Barrin if it were anyone else I’d ask if there’s more to the story, but you’re like the least trollish person i know, he sounds ridiculous

With no regard for complexity/speed, first thing that comes to mind is...
- for each spot in the grid, mark if it's visited/unvisited
- iterate over the grid, if you hit an unvisited land piece, do islands++ and then recursively mark every bordering land piece "visited" to exhaust that island

I've grinded some hackerrank type sites and my approach would be a 2D array. That seems to be the easiest goto when dealing with a matrix.

Once you have the 2D array you have the ability to iterate through each point and the ones touching it vertically and horizontally, so then you have to write some logic to determine if each point is part of an island.

My immediate thought is using a function that takes a pixel and an object and recursively crawls the pixels looking for an edge and adding it to the object until it finds the edge.

Then as you iterate each pixel you check if its land or sea or part of an existing island and increment count before calling the function.

Let’s be real here. I’m a big troll but I wouldn’t target someone like that, that would just be mean.

Regarding the island question, if it’s what I think it is, sounds like the typical BFS question which I have done many times before. It’s really common.

BFS seems like a good thing to learn this weekend, and some other similar stuff.

The fact that a staff level cares about this makes me lose a lot of respect for him. Could understand it from a junior person.

I feel like I've stumbled across a nasty surprise in trying to use Cognito/API-Gateway/Lambda - no such thing as a server-side session.

JWT tokens expire after an hour. But according to some - users can still access resources after that. And you can't count on them to sign out the user, nor can you store sensitive user data in them or in local storage.

This thread is not encouraging: https://forums.aws.amazon.com/thread...hreadID=249168

What we need is the standard user session that we can put sensitive user data in, and functionality that automatically logs the user out after 15 minutes of inactivity (just browser-side isn't good enough). If the user does try to access a logged in resource - they're forced to re-authenticate. Like say a bank website.

I kinda thought Cognito would handle that - possibly in conjunction with API-Gateway. Argh. Standard solution is something like node with redis. But that defeats some of the point of lambda.

Haha i can’t remember the last time i used an IDE

Is cognito a necessity? That sounds like a major security flaw if you cant expire tokens easily

That's the whole point of JWT right? It's just not built to handle standard server-side user sessions - where you invalidate after 15 min. of activity, which also means you have to "touch" (reset to 15 min.) the session on every user action. J2EE and .net do that out of the box. Node uses a redis cluster or some other DB.

JWT can't do any of that - there's no DB of record for server side user sessions, just an authentication step and then maybe a re-authentication behind the scenes after an hour.

I kinda figured they'd build that into Cognito or API Gateway. But then again if you have real user sessions - that's a ton more functionality than just authentication - and could get crazy if a site has 10s or 100s of 1000s of logged in users.

Cognito solves a lot of problems for us wrt to federated login. Worst case I guess we might just add a node proxy layer that tracks user sessions.

The number one rule of security with jwts is that they aren't valid forever. The entire design of the jti claim on a token is to handle blacklisting of tokens. The expiration claim is specifically designed to handle time of access to a resource. Combined you basically have the scope of a "session" without any real state. The idea you can't immediately blacklist a token is poor design, that's how log outs work and a mechanism for protecting against stolen tokens

Anyways seems like you could add your own blacklist mechanism (dynamo?) and check if the token is black listed or not at the entry point of the lambda?

This is exactly what we do with JWT tokens, right down to the mechanism (Dynamo)

Yes you can do that. But you still have to keep track of when a user hasn't done anything for 15 minutes to know when to blacklist their token, AND reset that timer to 15 minutes any time the user accesses any back-end resource. Do you guys do that too somehow?

This is something that comes out of the box with a J2EE server, .NET, Express session store, and I'm guessing PHP and Rails have similar functionality.

Use case: let's say you have a bank website. You have some Javascript that warns a user their session is about to expire, then if they do nothing it triggers a back end logout. This will add their token to the blacklist. But, what if they already closed their browser 10 minutes ago? Now they could re-open it, try to access a back end resource, and get right through assuming the JWT token hadn't expired yet.

Even if you set the JWT token to expire in 15 minutes that still is a problem. Because if the user makes a request and the token is expired - the back end doesn't know if they had just made a request a minute before. So the back end won't know if it should refresh the user's token in the background, or force them to log in again.

Unless you're somehow resetting the token expiration on every request. No one does that right?

Also from my reading it seems like Cognito doesn't let you change the 1 hour expiration time. I could see one approach where we refresh if the token is 15 minutes old or more, but force the user to log in again if it's 30 minutes old or more. Assuming the business would be ok with 30 minutes as a max session time.

I feel like JWT works great for apps like FB where you just stay logged on forever. But for sensitive apps where you want to boot people after X minutes of inactivity - maybe not so much. And also there's the problem if you want to put sensitive data in the user session. You can't do it on the client side.

Also just out of curiosity - how are you checking this blacklist on every request? Does API Gateway check it somehow, then forward the request if the JWT isn't blacklisted?

Or does every other app in the eco-system always check the blacklist first before serving the user request? That approach could get messy with microservices.

I am sure theres a ton of ways to do this. Have a master expiration time (the longest a session can possibly last, say an hour of constant activity) and a short exp time (15 mins).

Each request check that both exp times are valid, if they are, serve the request and refresh the token as well (change the short exp time for 15 mins later).

Then use one of those lol. Spoiler alert: Session based security was wildly mishandled as well, security is hard.

The token expiration should handle this for you, a black list is just for when someone clicks a log out button or reports a stolen token.

The concept of a "server knowing" is not what jwts are for. If you want to store session information and state somewhere, do it. There's no need to be stateless just bc its cool if you don't want to. However, the jwt setting a specific exp time each time its generated is doing this for you. It only forces a login when its expired or blacklisted, how you change and alter the exp time on each request is up to you.

No one? You could do that. You can do whatever you want. Most people likely just set an exp time to 60 days and store it in local storage and go on about their days. Don't be most people.

No, jwts were created for very short applications. Staying logged in longer times is a harder problem with jwts and takes some finessing and research. Mostly I would just say focus on your use cases and stop worrying about whats "right". Just make sure you A) dont have a jwt in the wild that can be used a long time after its generation and B) dont store anything secret in a browser. Ez pz

I meant you could literally do it in your code. I dont know how all these AWS libs handle lambda security for you. We have our own OAuth server to check inter service requests for a valid jwt that it knows it signed. This includes checking a blacklist for its JTI and checking its EXP, and verifying its signer. We do it in code, so I have no idea what gateway or cognito does. We have client libs for each language that can do this, so its one function call in your code on each received request. Not very messy at all.

This would be the closest to what we want. But from my reading I haven't heard of anyone actually trying to refresh the JWT token on every request.

You could also get into some weird race condition states if right on the cusp of expiration. But I guess last one wins is ok.

I've never heard of a max session time even with constant activity. In that case I think you'd just refresh the JWT token behind the scenes and let the user keep working.

Hmmm although now I'm not 100% sure you can refresh it behind the scenes - can you? Would you have to store the user's credentials to log them in again? Maybe Cognito lets you do that somehow. We used to do that at my old job - but it was a homegrown IDM/token supplier thing. And then we still kept track of the user's session on our end.

It actually sounds like a fun problem to work on tbh. Im jealous

Yeah it will be interesting. Luckily we aren't a bank so these session requirements might not be set in stone. We might be able to get away with manual logout through JS (either by the user clicking logout or triggered by inactivity timeout) plus eventually session invalidation through token expiration.

This kinda sums up my issues with JWT: http://cryto.net/~joepie91/blog/2016...-for-sessions/

Which came from this HN article: https://news.ycombinator.com/item?id=11929267

This sums the issue/tradeoff up fairly well I think.

Seems like refresh tokens are what I was looking for - ways to re-authenticate a user behind the scenes. So your main token lives say 15 min. and your refresh token lives a couple days.

If the user makes a request and the main token is expired, but less than 15 minutes ago - you use the refresh token to log them in behind the scenes. If the main token is more than 15 minutes old you force them to log in again.

Where do you store the refresh token?

Im only about halfway through this btw, but could be interesting:
https://medium.com/lightrail/getting...on-57d0c6474e3

Usually on the client. So the client code handles the refresh. That quote I posted is discussing the non-standard option of storing it server-side somewhere.

Ok yeah he's updating the JWT payload expiry on each request. That could be the way to go. Not sure if it will play nice with cognito but I can try.

This whole approach is great. It should become part of the JWT spec imo.

The more I think of it I can't think of a single thing it can't do that I want - except maybe store big objects in the session (due to cookie size limits). But it seems like you could work around that with encrypted payloads to be stored in browser session storage.

ya I am now in a full on battle with this women. she told me I needed to "forget everything I have ever learned" and then in my PR made a really snarky comment that implied I dont "deliver quality". to me, there is really no coming back from the first comment. she basically said that my expertise was crap and I didnt understand how to do anything and also showed that she thought she knew better than me.

the thing is, I didnt respond nor let on that I thought it was a garbage thing to say. Ive done my best to just steer clear of her but she just keeps gunning for me and now she wants to meet and its just unavoidable. I obv should have just sat on my thumbs and not written the code but I was bored and the solution was just staring me in the face for like 3 days while she dicked around. sorry honey, if you are gonna get that offended then maybe get some damn work done. hell, if she would have just put up a pr with her work I would have held back but there was just nothing done.

Mind you, I was given praise for the design from one of the 3 tech leads of the whole program and another reviewer so it just shows that her criticisms are complete bs.

she wants to sit down with me and "discuss my attitude and how I communicate". it really is going to take all of my willpower not to verbally retaliate to her bullsht criticism and passive aggressive snarkiness.

I really need a new job. its too bad bc I finally got to write some code in the last month and actually create working things.