| 6 Oct 2024 |
 wother | again, if it is a dev dep, whatever, that is on your local box and I only care as far as it doesn't exploit others.
but in production... hell no, never. | 21:51:29 |
| wother | Forwarded message from Abhi
btw do this https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally | 21:48:06 |
 Abhi | This is what i do -
mkdir -p ~/.npm-global
npm config set prefix '~/.npm-global'
export PATH=$HOME/.npm-global/bin:$PATH #in my .ksh.rc
source ~/.kshrc | 21:47:08 |
| Abhi | I agree. | 21:51:54 |
| Abhi | Who's akido? | 21:53:31 |
| wother | links are blocked, as a bunch of peeps were sharing copywritten stuff and we lost a room because of strikes... damn trolls. | 21:48:53 |
| Abhi | In reply to Abhi
Poll: When you use npm to install packages. (If you do use it) Many packages readme suggest to install it globally with -g . You need root privileges. Do use sudo when it errors out? it suggests to use root
- Yes
- No
Vote with !tg vote YwBYDkRXAAABfmA <choice number> I asked in many dev groups, 46% just use sudo because " i just want to get it done" | 21:50:37 |
| Abhi | So cool ! i never used it. Time to learn about it, thanks wother | 21:54:35 |
| wother | lol, it is honestly more annoying than anything, but I don't care. I'm on the SysOps team now, so I just make sure the environment is secure and online. | 21:55:22 |
| wother | I know stuff like nodemon or some linters want to be global, but those are dev deps, not prod deps.
Prod should NEVER need root/elevated permissions. | 21:50:42 |
| Abhi | This is based! | 21:53:51 |
| 7 Oct 2024 |
|  Martin Välba: 🇪🇪 / changed their display name from Martin Välba to Martin Välba: 🇪🇪 /. | 16:05:00 |
| 8 Oct 2024 |
 #!/usr/bin/env h@x | In reply to wother
lol, it is honestly more annoying than anything, but I don't care. I'm on the SysOps team now, so I just make sure the environment is secure and online. And im gonna dip into Devops Engineering 🙃 | 11:20:42 |
 ᴘʀᴏғғᴀᴘᴛ | In reply to #!/usr/bin/env h@x
And im gonna dip into Devops Engineering 🙃 First time hearing DevOps & Engineering together XD | 11:58:47 |
| #!/usr/bin/env h@x | In reply to ᴘʀᴏғғᴀᴘᴛ
First time hearing DevOps & Engineering together XD Not the first time here tho ^^ | 14:10:08 |
| 10 Oct 2024 |
|  Deleted account 6954747145 changed their display name from .... to Deleted account 6954747145. | 16:43:58 |
| 11 Oct 2024 |
|  Deleted account 1292293364 changed their display name from Alex 🌘 to Deleted account 1292293364. | 16:30:38 |
| 12 Oct 2024 |
 I75k1ddy | Hi frands
Having some doubt on Jwt authentication | 13:22:26 |
| I75k1ddy | If I logout using 'xyz' token
Then Using the same token to access isAuthenticated endpoints (endpoints which requires user to be logged in to access ) , will i be able to access it ? | 13:23:28 |
| ᴘʀᴏғғᴀᴘᴛ | In reply to I75k1ddy
If I logout using 'xyz' token
Then Using the same token to access isAuthenticated endpoints (endpoints which requires user to be logged in to access ) , will i be able to access it ? Yes if the token isn't expired. | 16:37:32 |
| #!/usr/bin/env h@x | Thats for your own safety.
Just think about cookie stealer. | 16:55:57 |
 h4ck3r@parrot | In reply to I75k1ddy
If I logout using 'xyz' token
Then Using the same token to access isAuthenticated endpoints (endpoints which requires user to be logged in to access ) , will i be able to access it ? During logout u clear the cookies naa .. if u are not clearing then what's the point of logout ? | 16:43:01 |
| h4ck3r@parrot | In reply to #!/usr/bin/env h@x
Thats for your own safety.
Just think about cookie stealer. Well .. I do have httponly enabled for most like for refresh token etc .. so most won't work until the user decides to give away ..
And I clear from the backend .. like I'll do a set-cookie on the jet token and set it as 0 or something | 16:59:07 |
| wother | In reply to I75k1ddy
If I logout using 'xyz' token
Then Using the same token to access isAuthenticated endpoints (endpoints which requires user to be logged in to access ) , will i be able to access it ? Depends on how the dev rolled the JWT.
When I did it we have our tokens 4 hours, and the option to refresh expired tokens on the fly. But we weren't exposing anything too sensitive.
My current stack is more restrictive. | 17:01:59 |
| h4ck3r@parrot | In reply to wother
Depends on how the dev rolled the JWT.
When I did it we have our tokens 4 hours, and the option to refresh expired tokens on the fly. But we weren't exposing anything too sensitive.
My current stack is more restrictive. Ah putting sensitive data in jws is not a good idea .. that's why jwes exist | 17:42:23 |
| h4ck3r@parrot | Hm .. I guess I should move on from curl | 19:16:43 |
| h4ck3r@parrot | Ooh ... I see ..
Is postman that good ? .. I see alot of ppl use it | 19:15:48 |
| I75k1ddy | Yeah, it is | 19:16:21 |
| I75k1ddy | In reply to wother
Depends on how the dev rolled the JWT.
When I did it we have our tokens 4 hours, and the option to refresh expired tokens on the fly. But we weren't exposing anything too sensitive.
My current stack is more restrictive. Within that 4 hours who has access to token still access private endpoints untill its expired! | 19:15:53 |
| I75k1ddy | In reply to h4ck3r@parrot
During logout u clear the cookies naa .. if u are not clearing then what's the point of logout ? Was doing API testing with postman | 19:14:04 |
