pmhsfelix

1. Download JDK 20 EA (Early Access) build from https://jdk.java.net/20/ and unzip it to a local folder.
2. On build.gradle.kts, add

// to use JDK 20 for the build and execution
java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(20))
    }
}

pmhsfelix

1. Motivation
   • Reactive streams as extended futures.
     • A future (potentially) produces a single value at a single moment in time. The value can be a list, but all the list's elements need to be produced at the same time. However there are activities that produce multiple values, spread over time (e.g. v_0 at t_0, v_1 at t_1, v_2 at t_2 ).
     • A future represents an operation that already started. There isn't anything on the future's interface to start (or restart) a new operation.
     • A reactive stream can be viewed as a future that produces more than one value through its lifetime, and whose operation is only triggered when a consumer subscribes to the stream.
   • Reactive streams as push-style iterables/enumerables.

• On a iterable/enumerable, elements are pulled by consumers (e.g. by calling next or MoveNext). If a value is not available, that call will block until the value becomes. Due to this, they aren't a good fit to when the element's availability

pmhsfelix

• Create a single classroom for all class sections ("turmas") in a single semester.
  • E.g. "Programação Concorrente 2020/2021 Inverno"
• Create a single assignment for each class section.
  • A repository is automatically created when a student accepts an assignment.
  • Same assignment for all problem sets or distinct assignment for each problem set.
    • This semester I'm using the same assignment for all problem sets.
  • E.g. s2021-li51d-student
    • It's important to have the semester identifier to distinguish between semesters.
    • The student segment allows for easy searching.
• Use a template repository when creating the assignment. This way we can (try to) control its organization.

pmhsfelix

// l10n example based on the https://tools.ietf.org/html/rfc7807 example
{
   "type": "https://example.net/validation-error",
   "title": "Your request parameters didn't validate.",
   "titleKey": "invalid.parameters.key"
   "invalid-params": [ {
                         "name": "age",
                         "reason": "must be a positive integer",
                         "reasonKey": "must.be.positive.integer"
                       },

pmhsfelix

The following code ...

@Test
fun nested_coroutines5() {
    log.info("start")
    val res = runBlocking {
        launch {
            launch {
                completeAfter(2500)
            }

pmhsfelix

# Push model #

* Node A is the authoritative source on some resource R
* Node B is interested on R's state
* Instead of B doing a GET on A (pull) we use a push model where A does a PUT on B
  * HTTP roles are reversed - the HTTP client doing the PUT (node A) is authoritative for the resource R
  * A decides the most appropriate times to do this push
  * A is also the authoritative source on R's ETag
    * A includes this ETag as a *request* header on the PUT (which is odd, since ETag is defined as a response header on the HTTP spec)
    * B doesn't know how to compute the ETag. For instance, a GET/HEAD to B will return the ETag PUTed by A 

pmhsfelix

{
  "problemCount": 2,
  "resources": [
    {
      "rel": "https://example.com/rels/payment",
      "title": "payment gateway",
      "id": "https://example.com/ids/paymentgateway/1",
      "date": "Tue, 15 Nov 1994 08:12:31 GMT",
      "state": "ok"      
    },

pmhsfelix

Scenario

• Use IdSrv3 as an OAuth 2.0 Authorization Server only.
• Use legacy authentication pages and session management mechanism.
• No Federation Gateway functionality is required.
• The IdSrv3 built in page should never be rendered to the user.

Solution

• Create a IUserService implementation with the following behavior on the PreAuthenticateAsync method.

pmhsfelix

• Use an OAuth 2.0 Authorization Server (AS) to issue access tokens containing (or refering to) the required information, typically the user's identity (i.e. resource owner identity), the client app identity and the authorization scope.
• The Web API (i.e. the Resource Server) will only accept access tokens from the AS. Namely, the Web API will not have to deal with tokens from the external identity providers.
• The AS will delegate the user's authentication process to an external identity provider, therefore also acting as an Federation Gateway.
• If account linking is necessary (e.g. linking two different external accounts to one internal account), then this can be done at the AS level. Otherwise, the AS will only forward the external identity claims into the Web API.
• IdentityServer 3 can be used to implement both the AS and the Federation Gateway functionality. There is OWIN Middleware available to process access tokens issued by IdentityServer 3.
• If the Web API is OWIN based (or supports OWIN middlewa

pmhsfelix

{
    "projects": [
        "src"
        ,"C:/home/code/cli/asp.net.5/Hosting/src"
        ,"C:/home/code/cli/asp.net.5/KestrelHttpServer/src"
        ,"C:/home/code/cli/asp.net.5/HttpAbstractions/src"
        ,"C:/home/code/cli/asp.net.5/Mvc/src"
    ]
}