mirror of
https://github.com/nsnail/Ocelot.git
synced 2025-06-19 19:38:16 +08:00
+semver: upgrade to net5.0 (#1390)
* breaking upgrade base build image to net5.0 * add make and build tools to image * fix code broken after net5.0 upgrade * fix warnings * fix tests and line endings * upgrade dotnet test and coverages packages * update circle build image * removed rafty and updated more packages * bring back develop * rename authorisation to authorization
This commit is contained in:
@ -1,7 +1,7 @@
|
||||
Release process
|
||||
===============
|
||||
|
||||
* The release process works best with GitHubFlow branching.
|
||||
* The release process works best with Git Flow branching.
|
||||
* Contributors can do whatever they want on PRs and merges to master will result in packages being released to GitHub and NuGet.
|
||||
|
||||
Ocelot uses the following process to accept work into the NuGet packages.
|
||||
@ -10,7 +10,7 @@ Ocelot uses the following process to accept work into the NuGet packages.
|
||||
|
||||
2. User creates a fork and branches from this (unless a member of core team, they can just create a branch on the main repo) e.g. feat/xxx, fix/xxx etc. It doesn't really matter what the xxx is. It might make sense to use the issue number and maybe a short description. I don't care as long as it has (feat, fix, refactor)/xxx :)
|
||||
|
||||
3. When the user is happy with their work they can create a pull request against master in GitHub with their changes. The user must follow the `SemVer <https://semver.org/>`_ support for this is provided by `GitVersion <https://gitversion.readthedocs.io/en/latest/>`_. So if you need to make breaking changes please make sure you use the correct commit message so GitVersion uses the correct semver tags. Do not manually tag the Ocelot repo this will break things.
|
||||
3. When the user is happy with their work they can create a pull request against develop in GitHub with their changes. The user must follow the `SemVer <https://semver.org/>`_ support for this is provided by `GitVersion <https://gitversion.readthedocs.io/en/latest/>`_. So if you need to make breaking changes please make sure you use the correct commit message so GitVersion uses the correct semver tags. Do not manually tag the Ocelot repo this will break things.
|
||||
|
||||
4. The Ocelot team will review the PR and if all is good merge it, else they will suggest feedback that the user will need to act on. In order to speed up getting a PR the user should think about the following.
|
||||
- Have I covered all my changes with tests at unit and acceptance level?
|
||||
@ -23,9 +23,11 @@ In order for a PR to be merged the following must have occured.
|
||||
- Build must not have slowed down dramatically.
|
||||
- The main Ocelot package must not have taken on any non MS dependencies.
|
||||
|
||||
5. After the PR is merged to master the release process will begin which builds the code, versions it, pushes artifacts to GitHub and NuGet packages to NuGet.
|
||||
5. After the PR is merged to develop the Ocelot NuGet packages will not be updated until a release is created.
|
||||
|
||||
6. The final step is to go back to GitHub and close any issues that are now fixed. You should see something like this in`GitHub <https://github.com/ThreeMammals/Ocelot/releases/tag/13.0.0>`_ and this in `NuGet <https://www.nuget.org/packages/Ocelot/13.0.0>`_.
|
||||
6. When enough work has been completed to justify a new release. Develop will be merged into master the release process will begin which builds the code, versions it, pushes artifacts to GitHub and NuGet packages to NuGet.
|
||||
|
||||
7. The final step is to go back to GitHub and close any issues that are now fixed. You should see something like this in`GitHub <https://github.com/ThreeMammals/Ocelot/releases/tag/13.0.0>`_ and this in `NuGet <https://www.nuget.org/packages/Ocelot/13.0.0>`_.
|
||||
|
||||
Notes
|
||||
-----
|
||||
|
@ -12,19 +12,22 @@ This will bring down everything needed by the admin API.
|
||||
Providing your own IdentityServer
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
|
||||
All you need to do to hook into your own IdentityServer is add the following to your ConfigureServices method.
|
||||
|
||||
.. code-block:: csharp
|
||||
|
||||
public virtual void ConfigureServices(IServiceCollection services)
|
||||
{
|
||||
Action<IdentityServerAuthenticationOptions> options = o => {
|
||||
// o.Authority = ;
|
||||
// o.ApiName = ;
|
||||
// etc....
|
||||
Action<JwtBearerOptions> options = o =>
|
||||
{
|
||||
o.Authority = identityServerRootUrl;
|
||||
o.RequireHttpsMetadata = false;
|
||||
o.TokenValidationParameters = new TokenValidationParameters
|
||||
{
|
||||
ValidateAudience = false,
|
||||
};
|
||||
// etc....
|
||||
};
|
||||
|
||||
services
|
||||
.AddOcelot()
|
||||
|
@ -1,7 +1,7 @@
|
||||
Authentication
|
||||
==============
|
||||
|
||||
In order to authenticate Routes and subsequently use any of Ocelot's claims based features such as authorisation or modifying the request with values from the token. Users must register authentication services in their Startup.cs as usual but they provide a scheme (authentication provider key) with each registration e.g.
|
||||
In order to authenticate Routes and subsequently use any of Ocelot's claims based features such as authorization or modifying the request with values from the token. Users must register authentication services in their Startup.cs as usual but they provide a scheme (authentication provider key) with each registration e.g.
|
||||
|
||||
.. code-block:: csharp
|
||||
|
||||
@ -97,16 +97,14 @@ In order to use IdentityServer bearer tokens, register your IdentityServer servi
|
||||
public void ConfigureServices(IServiceCollection services)
|
||||
{
|
||||
var authenticationProviderKey = "TestKey";
|
||||
Action<IdentityServerAuthenticationOptions> options = o =>
|
||||
Action<JwtBearerOptions> options = o =>
|
||||
{
|
||||
o.Authority = "https://whereyouridentityserverlives.com";
|
||||
o.ApiName = "api";
|
||||
o.SupportedTokens = SupportedTokens.Both;
|
||||
o.ApiSecret = "secret";
|
||||
// etc
|
||||
};
|
||||
|
||||
services.AddAuthentication()
|
||||
.AddIdentityServerAuthentication(authenticationProviderKey, options);
|
||||
.AddJwtBearer(authenticationProviderKey, options);
|
||||
|
||||
services.AddOcelot();
|
||||
}
|
||||
|
@ -1,7 +1,7 @@
|
||||
Authorisation
|
||||
Authorization
|
||||
=============
|
||||
|
||||
Ocelot supports claims based authorisation which is run post authentication. This means if you have a route you want to authorise you can add the following to you Route configuration.
|
||||
Ocelot supports claims based authorization which is run post authentication. This means if you have a route you want to authorize you can add the following to you Route configuration.
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
@ -9,7 +9,7 @@ Ocelot supports claims based authorisation which is run post authentication. Thi
|
||||
"UserType": "registered"
|
||||
}
|
||||
|
||||
In this example when the authorisation middleware is called Ocelot will check to seeif the user has the claim type UserType and if the value of that claim is registered. If it isn't then the user will not be authorised and the response will be 403 forbidden.
|
||||
In this example when the authorization middleware is called Ocelot will check to seeif the user has the claim type UserType and if the value of that claim is registered. If it isn't then the user will not be authorized and the response will be 403 forbidden.
|
||||
|
||||
|
||||
|
@ -3,7 +3,7 @@ Claims Transformation
|
||||
|
||||
Ocelot allows the user to access claims and transform them into headers, query string parameters, other claims and change downstream paths. This is only available once a user has been authenticated.
|
||||
|
||||
After the user is authenticated we run the claims to claims transformation middleware. This allows the user to transform claims before the authorisation middleware is called. After the user is authorised first we call the claims to headers middleware, thenthe claims to query string parameters middleware, and Finally the claims to downstream pathmiddleware.
|
||||
After the user is authenticated we run the claims to claims transformation middleware. This allows the user to transform claims before the authorization middleware is called. After the user is authorized first we call the claims to headers middleware, thenthe claims to query string parameters middleware, and Finally the claims to downstream pathmiddleware.
|
||||
|
||||
The syntax for performing the transforms is the same for each process. In the Route configuration a json dictionary is added with a specific name either AddClaimsToRequest, AddHeadersToRequest, AddQueriesToRequest, or ChangeDownstreamPathTemplate.
|
||||
|
||||
|
@ -3,7 +3,7 @@ Http Error Status Codes
|
||||
|
||||
Ocelot will return HTTP status error codes based on internal logic in certain siturations:
|
||||
- 401 if the authentication middleware runs and the user is not authenticated.
|
||||
- 403 if the authorisation middleware runs and the user is unauthenticated, claim value not authroised, scope not authorised, user doesnt have required claim or cannot find claim.
|
||||
- 403 if the authorization middleware runs and the user is unauthenticated, claim value not authroised, scope not authorized, user doesnt have required claim or cannot find claim.
|
||||
- 503 if the downstream request times out.
|
||||
- 499 if the request is cancelled by the client.
|
||||
- 404 if unable to find a downstream route.
|
||||
|
@ -31,9 +31,9 @@ The user can set functions against the following.
|
||||
|
||||
* AuthenticationMiddleware - This overrides Ocelots authentication middleware.
|
||||
|
||||
* PreAuthorisationMiddleware - This allows the user to run pre authorisation logic and then call Ocelot's authorisation middleware.
|
||||
* PreAuthorizationMiddleware - This allows the user to run pre authorization logic and then call Ocelot's authorization middleware.
|
||||
|
||||
* AuthorisationMiddleware - This overrides Ocelots authorisation middleware.
|
||||
* AuthorizationMiddleware - This overrides Ocelots authorization middleware.
|
||||
|
||||
* PreQueryStringBuilderMiddleware - This allows the user to manipulate the query string on the http request before it is passed to Ocelots request creator.
|
||||
|
||||
|
@ -1,49 +0,0 @@
|
||||
Raft (EXPERIMENTAL DO NOT USE IN PRODUCTION)
|
||||
============================================
|
||||
|
||||
Ocelot has recently integrated `Rafty <https://github.com/ThreeMammals/Rafty>`_ which is an implementation of Raft that I have also been working on over the last year. This project is very experimental so please do not use this feature of Ocelot in production until I think it's OK.
|
||||
|
||||
Raft is a distributed concensus algorithm that allows a cluster of servers (Ocelots) to maintain local state without having a centralised database for storing state (e.g. SQL Server).
|
||||
|
||||
To get Raft support you must first install the Ocelot Rafty package.
|
||||
|
||||
``Install-Package Ocelot.Provider.Rafty``
|
||||
|
||||
Then you must make the following changes to your Startup.cs / Program.cs.
|
||||
|
||||
.. code-block:: csharp
|
||||
|
||||
public virtual void ConfigureServices(IServiceCollection services)
|
||||
{
|
||||
services
|
||||
.AddOcelot()
|
||||
.AddAdministration("/administration", "secret")
|
||||
.AddRafty();
|
||||
}
|
||||
|
||||
In addition to this you must add a file called peers.json to your main project and it will look as follows
|
||||
|
||||
.. code-block:: json
|
||||
|
||||
{
|
||||
"Peers": [{
|
||||
"HostAndPort": "http://localhost:5000"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5002"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5003"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5004"
|
||||
},
|
||||
{
|
||||
"HostAndPort": "http://localhost:5001"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
Each instance of Ocelot must have it's address in the array so that they can communicate using Rafty.
|
||||
|
||||
Once you have made these configuration changes you must deploy and start each instance of Ocelot using the addresses in the peers.json file. The servers should then start communicating with each other! You can test if everything is working by posting a configuration update and checking it has replicated to all servers by getting their configuration.
|
@ -44,8 +44,8 @@ Below is an example of the logging when set at Debug level for a normal request.
|
||||
requestId: asdf, previousRequestId: no previous request id, message: downstream template is {downstreamRoute.Data.Route.DownstreamPath},
|
||||
dbug: Ocelot.RateLimit.Middleware.ClientRateLimitMiddleware[0]
|
||||
requestId: asdf, previousRequestId: no previous request id, message: EndpointRateLimiting is not enabled for Ocelot.Values.PathTemplate,
|
||||
dbug: Ocelot.Authorisation.Middleware.AuthorisationMiddleware[0]
|
||||
requestId: 1234, previousRequestId: asdf, message: /posts/{postId} route does not require user to be authorised,
|
||||
dbug: Ocelot.Authorization.Middleware.AuthorizationMiddleware[0]
|
||||
requestId: 1234, previousRequestId: asdf, message: /posts/{postId} route does not require user to be authorized,
|
||||
dbug: Ocelot.DownstreamUrlCreator.Middleware.DownstreamUrlCreatorMiddleware[0]
|
||||
requestId: 1234, previousRequestId: asdf, message: downstream url is {downstreamUrl.Data.Value},
|
||||
dbug: Ocelot.Request.Middleware.HttpRequestBuilderMiddleware[0]
|
||||
|
@ -102,7 +102,7 @@ Unfortunately a lot of Ocelot's features are non websocket specific such as head
|
||||
9. Claims Transformation
|
||||
10. Caching
|
||||
11. Authentication - If anyone requests it we might be able to do something with basic authentication.
|
||||
12. Authorisation
|
||||
12. Authorization
|
||||
|
||||
I'm not 100% sure what will happen with this feature when it get's into the wild so please make sure you test thoroughly!
|
||||
|
||||
|
@ -26,7 +26,7 @@ Thanks for taking a look at the Ocelot documentation. Please use the left hand n
|
||||
features/servicefabric
|
||||
features/kubernetes
|
||||
features/authentication
|
||||
features/authorisation
|
||||
features/authorization
|
||||
features/websockets
|
||||
features/administration
|
||||
features/ratelimiting
|
||||
@ -41,7 +41,6 @@ Thanks for taking a look at the Ocelot documentation. Please use the left hand n
|
||||
features/middlewareinjection
|
||||
features/loadbalancer
|
||||
features/delegatinghandlers
|
||||
features/raft
|
||||
features/errorcodes
|
||||
|
||||
.. toctree::
|
||||
|
Reference in New Issue
Block a user