save
This commit is contained in:
parent
3b13ae4070
commit
9c8032c28c
15 changed files with 6992 additions and 491 deletions
File diff suppressed because it is too large
Load diff
Binary file not shown.
After Width: | Height: | Size: 183 KiB |
2
.orgids
2
.orgids
|
@ -1,2 +1,2 @@
|
|||
|
||||
(("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/journal/2021-04-16--12-27-13Z--iroh_auth_presentation.org" "83c6d508-003a-4c81-8385-b9fa13137b92" "e12ca021-c030-47f8-a9e5-4fb815a88735" "07dabe43-9563-430c-a729-87b5154d6d18" "dc5070c0-9040-4175-9a67-c85a21f65f35") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/archives/TODO.archive.org" #("B72E4288-E96B-4099-8684-37DDF3395C50" 0 36 (face org-property-value org-category "inbox" fontified t)) #("96343FD2-E7A9-4AAA-A40A-8D048DA340E9" 0 36 (org-category "inbox" face org-property-value fontified t)) "797ba971-6ae3-49a1-9499-928572760d09") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/inbox.org" "a4ebd43b-b589-499e-85e1-7ebea0abf3af") ("../y/her.esy.fun/src/posts/0013-how-to-choose-your-tools/index.org" "c2e61938-8493-434a-9ffa-9fd4698d9863") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/journal/2020/2020-09-26.org" "d6bfe273-22e1-40b4-92db-14b22e092498") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/journal/2020/2020-09-20.org" "8a931436-5db6-4ff1-8fa8-3415c1f67c61") ("../dev/her.esy.fun/src/drafts/XXXX-org-mode-intro/index.org" "21c48431-c0db-4a34-95fe-7228fea6233f") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/journal/2020-12-04--13-19-56Z--english_lesson.org" "1a758996-2bb0-4753-8365-34ca3ef0f940") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/journal/2021-04-16--12-27-13Z--iroh_auth_presentation.org" "dab23b61-a766-4eda-a1e9-1d39258ef5c0"))
|
||||
(("../y/her.esy.fun/src/posts/0019-utopia-tv-show/index.org" "88e25182-ee54-4d2e-b373-b4e06fc292c8") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/journal/2021-04-16--12-27-13Z--iroh_auth_presentation.org" "83c6d508-003a-4c81-8385-b9fa13137b92" "e12ca021-c030-47f8-a9e5-4fb815a88735" "07dabe43-9563-430c-a729-87b5154d6d18" "dc5070c0-9040-4175-9a67-c85a21f65f35" "dab23b61-a766-4eda-a1e9-1d39258ef5c0") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/archives/TODO.archive.org" #("B72E4288-E96B-4099-8684-37DDF3395C50" 0 36 (face org-property-value org-category "inbox" fontified t)) #("96343FD2-E7A9-4AAA-A40A-8D048DA340E9" 0 36 (org-category "inbox" face org-property-value fontified t)) "797ba971-6ae3-49a1-9499-928572760d09") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/inbox.org" "a4ebd43b-b589-499e-85e1-7ebea0abf3af") ("../y/her.esy.fun/src/posts/0013-how-to-choose-your-tools/index.org" "c2e61938-8493-434a-9ffa-9fd4698d9863") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/journal/2020/2020-09-26.org" "d6bfe273-22e1-40b4-92db-14b22e092498") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/journal/2020/2020-09-20.org" "8a931436-5db6-4ff1-8fa8-3415c1f67c61") ("../dev/her.esy.fun/src/drafts/XXXX-org-mode-intro/index.org" "21c48431-c0db-4a34-95fe-7228fea6233f") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/journal/2020-12-04--13-19-56Z--english_lesson.org" "1a758996-2bb0-4753-8365-34ca3ef0f940") ("../Library/Mobile Documents/iCloud~com~appsonthemove~beorg/Documents/org/journal/2021-05-01--11-03-58Z--impots_2020.org" "4591374a-9183-4698-bae4-38193e88bb8b"))
|
||||
|
|
|
@ -1,33 +0,0 @@
|
|||
# Created 2021-07-16 Fri 15:51
|
||||
#+TITLE: Cisco Notes #+Author: Yann Esposito
|
||||
#+AUTHOR: Yann Esposito
|
||||
* Device Flow [2021-07-16 Fri]
|
||||
|
||||
** Implications for IROH/SecureX/CTR
|
||||
|
||||
OAuth2 is about linking two accounts of the same person between two
|
||||
different services.
|
||||
|
||||
In the OAuth2 RFC only 4 *Grants* are described:
|
||||
|
||||
- Authorization Code*
|
||||
- Implicit (we explicitly removed the support in IROH-Auth)
|
||||
- Resource Owner Password Credentials
|
||||
- Client Credential*
|
||||
|
||||
With these we handle:
|
||||
|
||||
- scripts
|
||||
- websites with a backend
|
||||
|
||||
** Native Applications & SPA (PKCE)
|
||||
|
||||
An additional RFC exists to improve the support of Native Applications and
|
||||
Single Page Applications.
|
||||
|
||||
It was easily introduced a few years back for SSE.
|
||||
|
||||
** Device Grant
|
||||
|
||||
- *All on-premise devices*
|
||||
- *All devices without input access or browser access*.
|
|
@ -1,206 +0,0 @@
|
|||
# Created 2021-07-01 Thu 17:52
|
||||
#+TITLE: Cisco Notes #+Author: Yann Esposito
|
||||
#+AUTHOR: Yann Esposito
|
||||
* Device Flow [2021-07-01 Thu]
|
||||
|
||||
** Prior to the Flow
|
||||
|
||||
All devices must have a client_id/client_secret to be able to perform the
|
||||
flow.
|
||||
So for all FMC we must create a new OAuth2 Device Grant client.
|
||||
Simply give the scopes and the =grants= must be =["device-grant"]=.
|
||||
|
||||
That's it!
|
||||
|
||||
**No =redirect_uri=**
|
||||
|
||||
*** Work to be done once by the Team (FMC)
|
||||
|
||||
The JWT of the owner of the client (an FMC developer).
|
||||
|
||||
#+name: intmasterjwt
|
||||
#+begin_src elisp
|
||||
"eyJhbGciOiJS...."
|
||||
#+end_src
|
||||
|
||||
#+header: :var jwt=intmasterjwt
|
||||
#+begin_src http
|
||||
POST https://visibility.int.iroh.site/iroh/oauth2-clients/clients
|
||||
Accept: application/json
|
||||
Content-Type: application/json
|
||||
User-Agent: ob-http
|
||||
Authorization: Bearer ${jwt}
|
||||
|
||||
{
|
||||
"scopes": ["profile","inspect"],
|
||||
"description": "Device Grant Demo Client",
|
||||
"availability": "everyone",
|
||||
"name": "Device Grant Demo",
|
||||
"grants": ["device-grant"]
|
||||
}
|
||||
#+end_src
|
||||
|
||||
#+results:
|
||||
#+begin_src http
|
||||
{
|
||||
"scopes": [
|
||||
"profile",
|
||||
"inspect"
|
||||
],
|
||||
"description": "Device Grant Demo Client",
|
||||
"approved?": true,
|
||||
"redirects": [],
|
||||
"availability": "everyone",
|
||||
"password": "Hkd4ihtMG2Ivr0gm7UPVgED2iyWFjNLjaC403TN7z11VKB5VyU25xg",
|
||||
"name": "Device Grant Demo",
|
||||
"org-id": "63489cf9-561c-4958-a13d-6d84b7ef09d4",
|
||||
"enabled?": true,
|
||||
"grants": [
|
||||
"device-grant"
|
||||
],
|
||||
"client-type": "confidential",
|
||||
"id": "client-27d76a9a-3697-42f8-b492-2e21043afa92",
|
||||
"approval-status": "approved",
|
||||
"owner-id": "6ee52ee9-2e3a-4e1b-977d-961facb5fd84",
|
||||
"created-at": "2021-07-01T09:49:49.372Z"
|
||||
}
|
||||
#+end_src
|
||||
|
||||
|
||||
*** Side-note
|
||||
|
||||
IROH-Auth declares it supports the Device Grant Flow in the =.well-known=.
|
||||
Thus client applications developers could probably use tools that support
|
||||
the Device Grant OAuth2 feature.
|
||||
|
||||
#+begin_src http
|
||||
GET https://visibility.int.iroh.site/.well-known/oauth-authorization-server
|
||||
Accept: application/json
|
||||
Content-Type: application/json
|
||||
User-Agent: ob-http
|
||||
#+end_src
|
||||
|
||||
** The Flow
|
||||
|
||||
The user should access a Device.
|
||||
When the user want to link its SecureX account into the device.
|
||||
The device makes a *POST* to SecureX to retrieve both a **=user_code=** and
|
||||
a **=device_code=**.
|
||||
|
||||
#+begin_src http
|
||||
POST https://visibility.int.iroh.site/iroh/oauth2/device_authorization
|
||||
Accept: application/json
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
User-Agent: ob-http
|
||||
|
||||
client_id=client-27d76a9a-3697-42f8-b492-2e21043afa92&
|
||||
client_secret=Hkd4ihtMG2Ivr0gm7UPVgED2iyWFjNLjaC403TN7z11VKB5VyU25xg
|
||||
#+end_src
|
||||
|
||||
#+results:
|
||||
#+begin_src http
|
||||
{
|
||||
"device_code": "ifZh-vMeNMVkH3ypyQpBzNEE7EPRlPgeeDP7OoTuB_A1p5jffGqjrw",
|
||||
"user_code": "2DCE2270",
|
||||
"verification_uri": "https://visibility.int.iroh.site/iroh/oauth2/device",
|
||||
"verification_uri_complete": "https://visibility.int.iroh.site/iroh/oauth2/device?user_code=2DCE2270",
|
||||
"expires_in": 600,
|
||||
"interval": 1
|
||||
}
|
||||
#+end_src
|
||||
|
||||
After that, the device should do two things:
|
||||
|
||||
1. Display the **user_code** and ask the user to go to SecureX to
|
||||
grant the Device
|
||||
2. Continuously polling SecureX to get the user's access/refresh tokens
|
||||
|
||||
|
||||
*** Polling before the user grant (or not) the client
|
||||
|
||||
#+begin_src http
|
||||
POST https://visibility.int.iroh.site/iroh/oauth2/token
|
||||
Accept: application/json
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
User-Agent: ob-http
|
||||
|
||||
client_id=client-27d76a9a-3697-42f8-b492-2e21043afa92&
|
||||
client_secret=Hkd4ihtMG2Ivr0gm7UPVgED2iyWFjNLjaC403TN7z11VKB5VyU25xg&
|
||||
grant_type=urn:ietf:params:oauth:grant-type:device_code&
|
||||
device_code=ifZh-vMeNMVkH3ypyQpBzNEE7EPRlPgeeDP7OoTuB_A1p5jffGqjrw
|
||||
#+end_src
|
||||
|
||||
#+results:
|
||||
#+begin_src http
|
||||
{"client-id":"client-27d76a9a-3697-42f8-b492-2e21043afa92",
|
||||
"trace_id": "f41a5c4b-2c6b-4130-89d7-1aa91542fc16",
|
||||
"error_description":"Authorization pending",
|
||||
"error_uri":"https://datatracker.ietf.org/doc/html/rfc8628#section-3.5",
|
||||
"error":"authorization_pending"}
|
||||
#+end_src
|
||||
|
||||
The HTTP code is *400*;
|
||||
|
||||
*** Ask the user to grant the Device
|
||||
|
||||
1. Go to the generic "Enter the code page" (=verification_uri=)
|
||||
2. Send the user to a prefilled with the code "Grant the Client Page"
|
||||
(=verification_uri_complete=).
|
||||
|
||||
**Remarks**:
|
||||
- We could use a QRCode if the device is not reachable via a Browser.
|
||||
- We should probably use a URL shortener for the =verification_uri=.
|
||||
|
||||
*** Polling for user answer/credentials
|
||||
|
||||
After the user granted the client:
|
||||
|
||||
#+begin_src http
|
||||
POST https://visibility.int.iroh.site/iroh/oauth2/token
|
||||
Accept: application/json
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
User-Agent: ob-http
|
||||
|
||||
client_id=client-27d76a9a-3697-42f8-b492-2e21043afa92&
|
||||
client_secret=Hkd4ihtMG2Ivr0gm7UPVgED2iyWFjNLjaC403TN7z11VKB5VyU25xg&
|
||||
grant_type=urn:ietf:params:oauth:grant-type:device_code&
|
||||
device_code=ifZh-vMeNMVkH3ypyQpBzNEE7EPRlPgeeDP7OoTuB_A1p5jffGqjrw
|
||||
#+end_src
|
||||
|
||||
#+results:
|
||||
#+begin_src http
|
||||
{
|
||||
"access_token": "eyJhbGciOi...",
|
||||
"scope": "profile inspect",
|
||||
"token_type": "bearer",
|
||||
"expires_in": 600,
|
||||
"refresh_token": "eyJhb...."
|
||||
}
|
||||
#+end_src
|
||||
|
||||
**Remark**:
|
||||
Any further attempt result in a 404:
|
||||
|
||||
|
||||
#+begin_src http
|
||||
POST https://visibility.int.iroh.site/iroh/oauth2/token
|
||||
Accept: application/json
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
User-Agent: ob-http
|
||||
|
||||
client_id=client-27d76a9a-3697-42f8-b492-2e21043afa92&
|
||||
client_secret=Hkd4ihtMG2Ivr0gm7UPVgED2iyWFjNLjaC403TN7z11VKB5VyU25xg&
|
||||
grant_type=urn:ietf:params:oauth:grant-type:device_code&
|
||||
device_code=ifZh-vMeNMVkH3ypyQpBzNEE7EPRlPgeeDP7OoTuB_A1p5jffGqjrw
|
||||
#+end_src
|
||||
|
||||
#+results:
|
||||
#+begin_src http
|
||||
{
|
||||
"client-id": "client-27d76a9a-3697-42f8-b492-2e21043afa92",
|
||||
"error_uri": "https://datatracker.ietf.org/doc/html/rfc8628#section-3.5",
|
||||
"trace_id": "522a5c4b-2c6b-4130-89d7-1aa91542fc16",
|
||||
"error": "invalid_device_code",
|
||||
"error_description": "device code not found"
|
||||
}
|
||||
#+end_src
|
|
@ -74,3 +74,12 @@ Service is like an object in object oriented programming.
|
|||
With some differences.
|
||||
Services in your application should form a graph.
|
||||
There is a dependency graph between your running services.
|
||||
|
||||
FooService:
|
||||
foo1
|
||||
foo2
|
||||
foo3
|
||||
|
||||
BarService:
|
||||
bar1
|
||||
bar2
|
||||
|
|
|
@ -1,71 +0,0 @@
|
|||
#+TITLE: Service Oriented Programming
|
||||
#+Author: Yann Esposito
|
||||
#+Date: [2021-06-06]
|
||||
|
||||
- tags :: [[file:2020-06-03--19-49-30Z--programming.org][programming]] [[file:2021-03-20--17-27-46Z--architecture.org][architecture]]
|
||||
- source ::
|
||||
|
||||
This is a presentation of a design pattern to architecture a big source code.
|
||||
The focus of this paradigm is composability (which is superior to
|
||||
modularity from my perspective).
|
||||
|
||||
This focus on improving locality of impact.
|
||||
If you change a file, it should has most impact locally in the same "service-block".
|
||||
And could have an impact on transitively dependant "service-blocks".
|
||||
|
||||
First, this focus on functions.
|
||||
There will be no global variable.
|
||||
There are two kind of functions in programming, pure and impure functions.
|
||||
|
||||
A great deal is made about state management and purity.
|
||||
From a high level perspective:
|
||||
|
||||
- =lib/= contain only pure functions (YES!)
|
||||
- =services/= contain all services
|
||||
|
||||
**Important** every service can have at most ONE running instance.
|
||||
This is probably the most controversial choice about this architecture.
|
||||
|
||||
The services directory will contain "sub-project"/"modules".
|
||||
Every service should have the following structure:
|
||||
|
||||
- =src/=
|
||||
+ =service= the service declaration
|
||||
+ =core= the implementation of the function in the service, should
|
||||
contain pure functions
|
||||
+ =schemas/types= the metas structures (data format mostly)
|
||||
+ =routes= if you service is a web service, routes declarations
|
||||
- =test/=
|
||||
+ =service_test= the service test
|
||||
+ =core_test= the tests for pure functions
|
||||
|
||||
|
||||
A service should be considered as a function returning a record of functions.
|
||||
|
||||
#+begin_src
|
||||
foo-service-methods
|
||||
foo-do-a
|
||||
foo-do-b
|
||||
foo-do-c
|
||||
|
||||
def foo-service
|
||||
create-service( config-service, bar-service, baz-service)
|
||||
#+end_src
|
||||
|
||||
The component will form an acyclic graph of dependencies.
|
||||
|
||||
Principles:
|
||||
|
||||
A service contain an internal state.
|
||||
Every service has at most single instance for the entire Application.
|
||||
Every method of the service can access this internal state.
|
||||
No OOP is needed, only functions.
|
||||
|
||||
Ability to test isolated.
|
||||
You can write:
|
||||
|
||||
|
||||
#+begin_src
|
||||
with-services-and-conf services conf
|
||||
test-the-services
|
||||
#+end_src
|
30
journal/2021/2021-06-07.org
Normal file
30
journal/2021/2021-06-07.org
Normal file
|
@ -0,0 +1,30 @@
|
|||
#+Title: Journal (2021-06-07 - ∆y=44.26 (16165))
|
||||
#+Author: Yann Esposito
|
||||
#+Date: [2021-06-07]
|
||||
#+STARTUP: showeverything
|
||||
#+STARTUP: inlineimages
|
||||
|
||||
* Résume Journée
|
||||
:PROPERTIES:
|
||||
:CREATED: 20210607
|
||||
:END:
|
||||
|
||||
| sommeil | ?/5 | horrible -> comme un bébé |
|
||||
| activité φ | ?/5 | au lit -> sport |
|
||||
| nourriture | ?/5 | malbouffe -> saine |
|
||||
| humeur | ?/5 | exécrable -> excellente |
|
||||
| intérêt | ?/5 | ennuie -> exceptionnel |
|
||||
|
||||
- Faits positifs
|
||||
- Faits marquants
|
||||
- Résumé des discussions intéressantes
|
||||
- Réflexions/Essais
|
||||
|
||||
* 2021-06-07 Monday
|
||||
** 09:57
|
||||
|
||||
Ce matin j'ai mené Anna chez le psychologue.
|
||||
Le RDV a été mal pris, du coups, nous nous sommes déplacés pour rien.
|
||||
Ça nous a permis de faire un petit tour avec Anna en voiture.
|
||||
|
||||
Krystelle a RDV à la mission locale avec Bastien, mais elle a mal au cou.
|
68
journal/2021/2021-07-08.org
Normal file
68
journal/2021/2021-07-08.org
Normal file
|
@ -0,0 +1,68 @@
|
|||
#+Title: Journal (2021-07-08 - ∆y=44.34 (16196))
|
||||
#+Author: Yann Esposito
|
||||
#+Date: [2021-07-08]
|
||||
#+STARTUP: showeverything
|
||||
#+STARTUP: inlineimages
|
||||
|
||||
* Résume Journée
|
||||
:PROPERTIES:
|
||||
:CREATED: 20210708
|
||||
:END:
|
||||
|
||||
** Matin
|
||||
:PROPERTIES:
|
||||
:CREATED: 20210708
|
||||
:END:
|
||||
|
||||
| sommeil | ?/5 | horrible -> comme un bébé |
|
||||
| humeur | ?/5 | exécrable -> excellente |
|
||||
| energie | ?/5 | exécrable -> excellente |
|
||||
|
||||
- Envies/Objectifs de la journées
|
||||
** Soirée
|
||||
:PROPERTIES:
|
||||
:CREATED: 20210708
|
||||
:END:
|
||||
| activité φ | ?/5 | au lit -> sport |
|
||||
| nourriture | ?/5 | malbouffe -> saine |
|
||||
| humeur | ?/5 | exécrable -> excellente |
|
||||
| energie | ?/5 | exécrable -> excellente |
|
||||
| intérêt | ?/5 | ennuie -> exceptionnel |
|
||||
|
||||
- Faits positifs
|
||||
- Faits marquants
|
||||
- Résumé des discussions intéressantes
|
||||
- Réflexions/Essais
|
||||
|
||||
* 2021-07-08 Thursday
|
||||
** 13:03
|
||||
Aujourd'hui encore une journée un peu classique.
|
||||
Je me suis fait réveillé par le réveil de Krystelle qui partait au travail.
|
||||
6h.
|
||||
Je m'étais endormi après minuit.
|
||||
Il faudra probablement que je fasse une sieste avant 15h30.
|
||||
|
||||
J'ai sorti le chien, je l'ai descendu jusqu'à la rivière.
|
||||
Il s'est baigné, à rencontré d'autres chiens.
|
||||
J'ai croisé la voisine avec sa fille deux fois.
|
||||
La première fois elle revenait à l'appartement, la seconde fois elle sortai
|
||||
Volcan son chien avec sa fille dans la poussette.
|
||||
|
||||
J'ai donné à mangé au chien.
|
||||
J'ai fait un café, regardé des news, le chat avec la team.
|
||||
J'ai discuté, vers 10h11 je suis allé vérifier que ma fille était bien
|
||||
réveillée.
|
||||
|
||||
Depuis que ma femme s'est acheté un kenwood chef patissier, je voulais
|
||||
manger de la mousse au chocolat.
|
||||
Et j'en ai profité, c'est ce que j'ai fait pendant qu'Anna finissait les
|
||||
reste du diner.
|
||||
|
||||
Au lieu de faire du vrai travail nous avons discuter de l'état de notre
|
||||
groupe, de Cisco, des embauches, etc...
|
||||
Enfin, on se fait chier, du coups, on déverse de la négativité.
|
||||
|
||||
Il va falloir que je fasse un effort conscient pour éviter de retomber là
|
||||
dedans.
|
||||
Maintenant je viens de finir la mousse au chocolat, de nettoyer, je vais
|
||||
jouer un peu à Factorio.
|
49
journal/2021/2021-07-19.org
Normal file
49
journal/2021/2021-07-19.org
Normal file
|
@ -0,0 +1,49 @@
|
|||
#+Title: Journal (2021-07-19 - ∆y=44.37 (16206))
|
||||
#+Author: Yann Esposito
|
||||
#+Date: [2021-07-19]
|
||||
#+STARTUP: showeverything
|
||||
#+STARTUP: inlineimages
|
||||
|
||||
* Résume Journée
|
||||
:PROPERTIES:
|
||||
:CREATED: 20210719
|
||||
:END:
|
||||
|
||||
** Matin
|
||||
:PROPERTIES:
|
||||
:CREATED: 20210719
|
||||
:END:
|
||||
|
||||
| sommeil | ?/5 | horrible -> comme un bébé |
|
||||
| humeur | ?/5 | exécrable -> excellente |
|
||||
| energie | ?/5 | exécrable -> excellente |
|
||||
|
||||
- Envies/Objectifs de la journées
|
||||
** Soirée
|
||||
:PROPERTIES:
|
||||
:CREATED: 20210719
|
||||
:END:
|
||||
| activité φ | ?/5 | au lit -> sport |
|
||||
| nourriture | ?/5 | malbouffe -> saine |
|
||||
| humeur | ?/5 | exécrable -> excellente |
|
||||
| energie | ?/5 | exécrable -> excellente |
|
||||
| intérêt | ?/5 | ennuie -> exceptionnel |
|
||||
|
||||
- Faits positifs
|
||||
- Faits marquants
|
||||
- Résumé des discussions intéressantes
|
||||
- Réflexions/Essais
|
||||
|
||||
* 2021-07-19 Monday
|
||||
** 08:43
|
||||
|
||||
Je me suis endormi très tard hier soir j'avais trop chaud.
|
||||
J'aurai aimé passer une week-end sans soucis de travail, mais il y a
|
||||
toujours du drama.
|
||||
|
||||
Ce matin, Krystelle est partie à la plage avec Anna.
|
||||
Bastien est parti au travail.
|
||||
Il n'y a que moi dans l'appartement.
|
||||
|
||||
Je suis en train de tester la mise à jour d'emacs.
|
||||
Pour l'instant je n'ai vu aucune différence.
|
|
@ -113,3 +113,5 @@ y aurait une description plus détaillée derrière chaque principe qui
|
|||
permettrait de comprendre la complexité et de l'appréhender pour comprendre
|
||||
quand on peut ou pas ne pas suivre certaines de ces règles littérales pour
|
||||
faire prévaloir l'intelligence humaine au cas par cas.
|
||||
|
||||
Enfin je m'égare un peu.
|
||||
|
|
37
refile.org
37
refile.org
|
@ -1,37 +0,0 @@
|
|||
* Internet situation
|
||||
Internet est devenu pour la majorité simplement le web.
|
||||
Et oui, le web est un succès commercial pour beaucoup.
|
||||
|
||||
Les jeunes ne savent même pas qu'un âge d'or de l'Internet existait avec le
|
||||
P2P.
|
||||
Certes l'age du P2P était loin d'être parfait.
|
||||
Rempli de spam, de contenu illegal, un manque de hiérarchie qui rendait
|
||||
tous les contenus égaux en terme de crédibilité/visibilité.
|
||||
|
||||
Mais c'est aussi ce qui en faisait son charme.
|
||||
Aujourd'hui nous avons des problèmes encore pire, mais avec des acteurs
|
||||
centralisés qui bénéficie de revenus considérables en imposant de la
|
||||
publicité de partout.
|
||||
Avec une capacité de contrôle et de censure qui est très souvent orienté
|
||||
contre l'intérêt commun en faveur de l'intérêt des plus forts.
|
||||
Une forme de WWW ou de système médiéval.
|
||||
|
||||
Peut-on réinventer un nouvel Internet ?
|
||||
Je pense que c'est un effort qui mérite reflexion.
|
||||
|
||||
Donc, au lieu d'avoir une application qui tourne sur notre PC qui donne
|
||||
accès aux photos de familles avec des connections encryptées sans que
|
||||
personne puisse regarder/analyser nos photos, videos, nous donnons nos
|
||||
données personnelles, nos commentaires, nos avis, nos photos, nos vidéos à
|
||||
des "Géant du Net".
|
||||
|
||||
Rien que pour cette raison, il est naturel de vouloir avoir à minima un
|
||||
système F2F.
|
||||
Aujourd'hui la seule application qui a toutes les features d'un internet
|
||||
privé est Retroshare.
|
||||
Il suffit de regarder l'UI de retroshare pour avoir une immédiate réaction
|
||||
de révultion.
|
||||
C'est horriblement môche, vieux, dans une application lourde.
|
||||
|
||||
Peut-être peut-on utiliser tout ce qui a été fait par retroshare, mais
|
||||
donner une interface web rajeunie.
|
BIN
roam/org-roam.db
BIN
roam/org-roam.db
Binary file not shown.
|
@ -1,141 +0,0 @@
|
|||
# Created 2021-05-27 Thu 17:05
|
||||
#+TITLE:
|
||||
#+AUTHOR: Yann Esposito
|
||||
* IN-PROGRESS Irina 1-1 prep :work:
|
||||
[2021-05-27 Thu 08:46]
|
||||
- ref ::
|
||||
|
||||
** What to talk about?
|
||||
|
||||
1. My personal history with Cisco (presentation) personality/env, etc...
|
||||
2. when/where I will be the more helpful to you
|
||||
3. generic welcome advices (the team, SecureX/CTRl, SBG, Cisco)
|
||||
4. what my day-to-day work looks like
|
||||
5. what am I relevant for, when should you reach out?
|
||||
6. the team spirit/ambiance
|
||||
7. The expected work
|
||||
8. Work organisation/schedule
|
||||
|
||||
|
||||
- Know more about my work:
|
||||
There is a 1h30 pres from previous week where I presented IROH-Auth to the
|
||||
larger team.
|
||||
|
||||
** Presentation (History first mine then the Team and the Product)
|
||||
|
||||
1. Ph.D. Machine Learning
|
||||
2. Post Ph.D. Machine Learning
|
||||
3. Work for Airfrace (Perl/scripts/web/)
|
||||
4. Join Vigiglobe via Guillaume (our wives worked together)
|
||||
1. Social Media Analytics, hire Matt, then G2
|
||||
2. lot of pressure, fullstack dev + machine learning
|
||||
3. rewrite in Clojure (lot of pressure)
|
||||
4. bad management (SCRUM hell), wrong decisions, lot of pressure
|
||||
5. Guillaume join Cisco in January, and I join in April.
|
||||
6. Recruited by Craig & Dean. Craig is the mastermind
|
||||
1. small team of 8 people, go to Calgary we are the center of attention
|
||||
(the future!). Meet Al Huger.
|
||||
2. first year work on CTIA (CTIM)
|
||||
3. Cisco Threat Response (CTR); names IROH/Visibility/CTR
|
||||
work on new abstractions / tk-store, inspect, modules, iroh-auth,
|
||||
admin interface, scripts, help ops.
|
||||
4. IROH-Auth: => login via AMP (SAML with Guillaume) (no user in DB)
|
||||
5. IROH-Auth: => login via Threatgrid (OpenId Connect client)
|
||||
6. IROH-Auth: => become OAuth2 provider (grants: client credentials,
|
||||
authorization code, implicit)
|
||||
**User** in DB
|
||||
7. Huge amount of support to help other team integrate with OAuth2.
|
||||
8. make implicit grant deprecated
|
||||
9. SSE Integration (big deal, difficult with many teams)
|
||||
House made integration (user auth hooks, pass tokens by side channels)
|
||||
Matthieu implication
|
||||
10. Orbital (they use our JWT)
|
||||
11. IROH-Auth: => become an OIDC provider (IROH-Auth can be used as an IdP)
|
||||
12. **SecureX** (previously called Platform, ...)
|
||||
Very deep change in IROH-Auth underlying architecture/business logic.
|
||||
8 month of intense work. Main change, user have only one
|
||||
=idp-mapping= and now have multiple =idp-mappings=. Mainly you can
|
||||
login via different login buttons and different identities into the
|
||||
same user inside SecureX.
|
||||
13. Ambrose then Victor join the team
|
||||
14. Craig & Dean resign both; this is *huge*, reorg even though it was
|
||||
prepared for one year.
|
||||
So, Jyoti is put on top of Guillaume, her team (Rob, Ag, Mark) merge
|
||||
with our team. Namrata / Elias replace Dean/Craig.
|
||||
|
||||
** Advices
|
||||
|
||||
1. *Evaluation*:
|
||||
Your main evaluation dimension will be *added user value*.
|
||||
- Cisco promote and encourage their employees, if you are useful you will be rewarded.
|
||||
- If you are helpful to other Cisco employees, this will also be visible
|
||||
- If you help to make the internal system work, this will be more
|
||||
difficult to sell to your manager. So my advice, have a 80/20 maximum
|
||||
about; 80% working on visible to your manager stuff, 20% on the
|
||||
necessary/fun stuff.
|
||||
2. Use Cisco resources, ask for it (I have an iMac for example, which is
|
||||
completely out of the normal things to get), do not be afraid to reach
|
||||
other people at Cisco. Note, I am not the best one to follow on this one ;)
|
||||
3. Try to use start-page, more and more people use it, I think this is a pretty
|
||||
good starting point (mothership/work.html).
|
||||
The frequency at which you will use these links (in 1 year from now) will be a good
|
||||
way to evaluate if you are on the right track.
|
||||
4. Do not fear to reach out to other people in other room/teams everyone
|
||||
will be friendly and helpful, this is in fact one of the most important
|
||||
hidden skill at Cisco.
|
||||
5. Try to be aware about the CoC (chain of command), because it is not clearly
|
||||
enforced does not mean it doesn't exists.
|
||||
6. If you have any issue/problem technical/human/HR anything don't wait, be
|
||||
vocal about it
|
||||
7. If you would like to work on something don't let your manager(s) guess
|
||||
for your ask them.
|
||||
8. Depending on your tasks you could be overwhelmed by communication channels
|
||||
(chat, mail, webexes), be prepared to handle this and have
|
||||
|
||||
** Day to Day
|
||||
|
||||
1. Open emacs, check my todo list
|
||||
2. Morning tours:
|
||||
- open webex teams, chat morning tour (from 10min to 8h, generally 30min)
|
||||
I frenquently have messages in the morning from Jyoti and other team
|
||||
from India, East Europe.
|
||||
- open mails (from 5min to 30min)
|
||||
- check the agenda webex invitations
|
||||
- Check my PRs (if someone has made some review, work on it)
|
||||
- Check opened PR for review (from 5min to 8h, generally I try to stay
|
||||
under 2h/day)
|
||||
- check chat in "the Frenchies" (we try to avoid it more and more)
|
||||
3. After the tour, check the updated agenda, the new todos, organize the
|
||||
day/priorities work on it (if I can). Number of chat interuption from
|
||||
10h-16h is generally about 4 notifications.
|
||||
4. During my afternoon (>16h, the US wakes up)
|
||||
- If no chat interruption continue the work until 18h/19h and stop my
|
||||
day.
|
||||
- Frequently one to three meetings, frequently during release weeks
|
||||
impromptu webex/chat with QA team.
|
||||
- If chat interruption, stop my work (unless my work is both urgent and
|
||||
need deep concentration) and focus on the chat. Generally from 16->19h30.
|
||||
Sometime a bit exceptionnally, work from 08:30pm->01:00am
|
||||
** What am I relevant about, when should you reach out?
|
||||
|
||||
- **IROH-Auth**: login, OAuth2, OpenID connect, OAuth2 clients, User/Org/Client
|
||||
management, **scopes**
|
||||
- **API Security**: **scopes**, how to use them, organize, etc...
|
||||
- **TK-Store**: access different DB with interfaces. Has been butchered a bit
|
||||
by Matthieu with its cache interface, he is aware about it.
|
||||
- **Inspect**: extract observables (IP, url, hashes, etc...) from raw text
|
||||
- **Response**: in Module system (iroh-int); now it is more Matthieu
|
||||
- **Admin interface**: hidden but *very important*
|
||||
- **Structured logs** (via Riemann/ES): helped get data for management: now
|
||||
should be moved to G2 (but I am still relevant for kibana access, how to
|
||||
log in our code, still missing structured log, but we are close)
|
||||
- **Code architecture**:
|
||||
- first decided to use lein-monolith (terrible but best from other
|
||||
terrible choices), then removed it recently. Take a look at
|
||||
=CONTRIBUTING.md=. Made =tk-tests= see rationale, etc...
|
||||
- =let-either= in =iroh-int= (monads, etc..)
|
||||
- =tk-store= is structured with the flaws from stores in CTIA
|
||||
- =defwebservice= to centralize how our webservices work
|
||||
** TODO Team spirit
|
||||
** TODO Expected work
|
||||
** TODO Work organization/schedule
|
Loading…
Reference in a new issue