Two Plus Two Publishing LLC
Two Plus Two Publishing LLC
 

Go Back   Two Plus Two Poker Forums > >

Notices

Programming Discussions about computer programming

Reply
 
Thread Tools Display Modes
Old 09-21-2018, 07:07 PM   #35351
Craggoo
culled
 
Craggoo's Avatar
 
Join Date: Sep 2006
Location: R.I.P. ItzPenzoo 12-09-11
Posts: 12,533
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by suzzer99 View Post
If you were stranded on a desert island and could only use one coding tool?
lol

Given a grid of 0s and 1s, determine how many "islands" there are in the grid. If anyone has ever played the Civilization games... if you imagine every in-game tile can be represented as 0 (sea) or land (1), calculate how many islands there are.
Craggoo is offline   Reply With Quote
Old 09-21-2018, 07:08 PM   #35352
jmakin
 
jmakin's Avatar
 
Join Date: Jan 2008
Location: Streaming
Posts: 28,506
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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
jmakin is online now   Reply With Quote
Old 09-21-2018, 07:56 PM   #35353
goofyballer
Carpal \'Tunnel
 
goofyballer's Avatar
 
Join Date: Jun 2005
Posts: 66,891
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by Craggoo View Post
lol

Given a grid of 0s and 1s, determine how many "islands" there are in the grid. If anyone has ever played the Civilization games... if you imagine every in-game tile can be represented as 0 (sea) or land (1), calculate how many islands there are.
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
goofyballer is offline   Reply With Quote
Old 09-21-2018, 09:26 PM   #35354
Larry Legend
Celtic Pride
 
Larry Legend's Avatar
 
Join Date: Jul 2009
Location: Kyrie's earth
Posts: 42,696
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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.
Larry Legend is offline   Reply With Quote
Old 09-21-2018, 10:20 PM   #35355
Barrin6
Carpal \'Tunnel
 
Barrin6's Avatar
 
Join Date: Dec 2005
Location: beyond legal blindness
Posts: 6,878
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by jmakin View Post
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
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.
Barrin6 is offline   Reply With Quote
Old 09-21-2018, 10:25 PM   #35356
Larry Legend
Celtic Pride
 
Larry Legend's Avatar
 
Join Date: Jul 2009
Location: Kyrie's earth
Posts: 42,696
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

BFS seems like a good thing to learn this weekend, and some other similar stuff.
Larry Legend is offline   Reply With Quote
Old 09-21-2018, 10:29 PM   #35357
muttiah
Carpal \'Tunnel
 
muttiah's Avatar
 
Join Date: Aug 2004
Posts: 23,457
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by Barrin6 View Post
Yea agreed. For the first time, I think I should have brought it up to him directly.

The first time was when another developer questioned the service contract, which I also expressed the same thoughts. Looking back, I should have help him save face and talked to him directly.

This second time, I should have just let it go since I have given up on this discussion before and let him have at it many months ago.

For context for the second one: the IDE allows us to optimize imports. Itís a natural thing to hit the hot key and let the IdE sort the imports. This Staff is adamant that we donít use it, despite the fact that we have been using it for all our other code bases. my argument is that it doesnít scale well and we should careless what the import statements are. Instead focus on coding and shipping. The way he does imports is way different than how the IDE does it.
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.
muttiah is offline   Reply With Quote
Old 09-21-2018, 10:50 PM   #35358
suzzer99
Save the Cheerleader, Save the World
 
suzzer99's Avatar
 
Join Date: Nov 2005
Location: on top of the bell curve
Posts: 92,117
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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.
suzzer99 is offline   Reply With Quote
Old 09-21-2018, 11:04 PM   #35359
jmakin
 
jmakin's Avatar
 
Join Date: Jan 2008
Location: Streaming
Posts: 28,506
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Haha i canít remember the last time i used an IDE
jmakin is online now   Reply With Quote
Old 09-21-2018, 11:05 PM   #35360
PJo336
THRILLHOUSE!
 
PJo336's Avatar
 
Join Date: Mar 2007
Posts: 21,887
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Is cognito a necessity? That sounds like a major security flaw if you cant expire tokens easily
PJo336 is offline   Reply With Quote
Old 09-22-2018, 12:29 AM   #35361
suzzer99
Save the Cheerleader, Save the World
 
suzzer99's Avatar
 
Join Date: Nov 2005
Location: on top of the bell curve
Posts: 92,117
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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.
suzzer99 is offline   Reply With Quote
Old 09-22-2018, 01:46 AM   #35362
PJo336
THRILLHOUSE!
 
PJo336's Avatar
 
Join Date: Mar 2007
Posts: 21,887
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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
PJo336 is offline   Reply With Quote
Old 09-22-2018, 01:57 AM   #35363
PJo336
THRILLHOUSE!
 
PJo336's Avatar
 
Join Date: Mar 2007
Posts: 21,887
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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?
PJo336 is offline   Reply With Quote
Old 09-22-2018, 11:06 AM   #35364
goofyballer
Carpal \'Tunnel
 
goofyballer's Avatar
 
Join Date: Jun 2005
Posts: 66,891
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by PJo336 View Post
Anyways seems like you could add your own blacklist mechanism (dynamo?) and check if the token is black listed or not
This is exactly what we do with JWT tokens, right down to the mechanism (Dynamo)
goofyballer is offline   Reply With Quote
Old 09-22-2018, 12:40 PM   #35365
suzzer99
Save the Cheerleader, Save the World
 
suzzer99's Avatar
 
Join Date: Nov 2005
Location: on top of the bell curve
Posts: 92,117
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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.

Last edited by suzzer99; 09-22-2018 at 01:03 PM.
suzzer99 is offline   Reply With Quote
Old 09-22-2018, 12:56 PM   #35366
suzzer99
Save the Cheerleader, Save the World
 
suzzer99's Avatar
 
Join Date: Nov 2005
Location: on top of the bell curve
Posts: 92,117
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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.
suzzer99 is offline   Reply With Quote
Old 09-22-2018, 01:20 PM   #35367
PJo336
THRILLHOUSE!
 
PJo336's Avatar
 
Join Date: Mar 2007
Posts: 21,887
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by suzzer99 View Post
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?
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).

Quote:
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.
Then use one of those lol. Spoiler alert: Session based security was wildly mishandled as well, security is hard.

Quote:
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.
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.

Quote:
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.
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.

Quote:
Unless you're somehow resetting the token expiration on every request. No one does that right?
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.

Quote:
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.
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
PJo336 is offline   Reply With Quote
Old 09-22-2018, 01:24 PM   #35368
PJo336
THRILLHOUSE!
 
PJo336's Avatar
 
Join Date: Mar 2007
Posts: 21,887
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by suzzer99 View Post
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 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.
PJo336 is offline   Reply With Quote
Old 09-22-2018, 01:28 PM   #35369
suzzer99
Save the Cheerleader, Save the World
 
suzzer99's Avatar
 
Join Date: Nov 2005
Location: on top of the bell curve
Posts: 92,117
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
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).
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.
suzzer99 is offline   Reply With Quote
Old 09-22-2018, 01:30 PM   #35370
PJo336
THRILLHOUSE!
 
PJo336's Avatar
 
Join Date: Mar 2007
Posts: 21,887
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

It actually sounds like a fun problem to work on tbh. Im jealous
PJo336 is offline   Reply With Quote
Old 09-22-2018, 01:36 PM   #35371
suzzer99
Save the Cheerleader, Save the World
 
suzzer99's Avatar
 
Join Date: Nov 2005
Location: on top of the bell curve
Posts: 92,117
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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.

Quote:
Think of it this way, the _real_ token is your refresh token. It's stored in your database. You control it and it can be revoked at any time. So, now you build 100 other services, and they all accept this refresh token. Problem is, since you control it so well, every other service now needs to validate that refresh token with the auth service on every request. It would be really nice if we could get around that massive traffic pinch point. So, we create crypto tokens that can be validated by every service without the need to make a network call. As a compromise, we make this new token expire in an hour so that the _client_ needs to validate their refresh token every hour and all our services are freed of from ever directly calling the auth service. Sure, this means that when you log out you're not really logged out for up to an hour, but it's all tradeoffs.

Last edited by suzzer99; 09-22-2018 at 01:44 PM.
suzzer99 is offline   Reply With Quote
Old 09-22-2018, 01:51 PM   #35372
suzzer99
Save the Cheerleader, Save the World
 
suzzer99's Avatar
 
Join Date: Nov 2005
Location: on top of the bell curve
Posts: 92,117
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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.
suzzer99 is offline   Reply With Quote
Old 09-22-2018, 01:55 PM   #35373
PJo336
THRILLHOUSE!
 
PJo336's Avatar
 
Join Date: Mar 2007
Posts: 21,887
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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
PJo336 is offline   Reply With Quote
Old 09-22-2018, 03:07 PM   #35374
suzzer99
Save the Cheerleader, Save the World
 
suzzer99's Avatar
 
Join Date: Nov 2005
Location: on top of the bell curve
Posts: 92,117
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

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.
suzzer99 is offline   Reply With Quote
Old 09-22-2018, 03:17 PM   #35375
suzzer99
Save the Cheerleader, Save the World
 
suzzer99's Avatar
 
Join Date: Nov 2005
Location: on top of the bell curve
Posts: 92,117
Re: ** UnhandledExceptionEventHandler :: OFFICIAL LC / CHATTER THREAD **

Quote:
Originally Posted by PJo336 View Post
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
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.

Last edited by suzzer99; 09-22-2018 at 03:42 PM.
suzzer99 is offline   Reply With Quote

Reply
      

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Forum Jump


All times are GMT -4. The time now is 03:56 AM.


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright © 2008-2017, Two Plus Two Interactive
 
 
Poker Players - Streaming Live Online