Are you over 18 and want to see adult content?
More Annotations
A complete backup of https://crookedtimber.org
Are you over 18 and want to see adult content?
A complete backup of https://erikalust.com
Are you over 18 and want to see adult content?
A complete backup of https://leafseitai.com
Are you over 18 and want to see adult content?
A complete backup of https://losrios.edu
Are you over 18 and want to see adult content?
A complete backup of https://intervarsity.org
Are you over 18 and want to see adult content?
A complete backup of https://gamepoint.com
Are you over 18 and want to see adult content?
A complete backup of https://gymboss.com
Are you over 18 and want to see adult content?
A complete backup of https://westminster.ac.uk
Are you over 18 and want to see adult content?
A complete backup of https://internetandtvconnect.com
Are you over 18 and want to see adult content?
A complete backup of https://citizenactionwi.org
Are you over 18 and want to see adult content?
A complete backup of https://southerntimesafrica.com
Are you over 18 and want to see adult content?
A complete backup of https://matoesfm.com.br
Are you over 18 and want to see adult content?
Favourite Annotations
A complete backup of howimetyourpapi.blogspot.com
Are you over 18 and want to see adult content?
A complete backup of yesilkartforum.com
Are you over 18 and want to see adult content?
A complete backup of weathercharts.org
Are you over 18 and want to see adult content?
A complete backup of childtocherish.com
Are you over 18 and want to see adult content?
A complete backup of animalbehaviorcollege.com
Are you over 18 and want to see adult content?
A complete backup of enioea2hw.wordpress.com
Are you over 18 and want to see adult content?
Text
* Linux
* Debian
* SLES
* Ubuntu
* Android
* Databases
* Sybase
* MySQL
* SybaseBuddy
* MySQLBuddy
* NoSQL
* ODBC
* Oracle
* Web
* WordPress
* Orchard CMS
* PHP
* CodeIgniter
* Laravel
* HTML
* HTML5
* JavaScript
* jQuery
* AngularJS
* CSS
* ASP.NET
* Apache-MySQL-PHP
* AMPPS
* MAMP
* Java
* CSharp
* Orchard CMS
* Mac
* Impressum
* About me
ANGULAR: USING A SERVICE TO LISTEN TO DOM EVENTS Posted on January 16, 2019by hb
In an Angular Component or a Directive, you can use the @HostListener decorator to listen to DOM events e.g.: @HostListener('document:click', ) private onClick(event: Event) {...
}
Using the decorator is very convenient. Unfortunately, it doesn’t work in Angular services. In a service, you have two options: * Using window.addEventListener * Using rxjs fromEvent The first option looks like this: document.addEventListener('click', () => {...
});
With the second option, it looks more angular-ishy: import { fromEvent } from 'rxjs';...
fromEvent(document, 'click').subscribe(() => {...
});
In order to test this (no matter which option, you’ve chosen above), you just need to do the following: document.dispatchEvent(new MouseEvent('click'));__
__
__
Google +
__
Posted in Angular
Leave a comment
OAUTH 2.0 / OPENID CONNECT EXPLAINED Posted on July 5, 2018July 9, 2018by hb
OAUTH AND OPENID CONNECT OAuth (Open Authorization) is an open standard for API access delegation. Put simply, it’s a secure authorization protocols used to grant applications access to protected resources without exposingcredentials.
OpenID Connect (OIDC) is an authentication layer (i.e. an identity layer) on top of OAuth 2.0. Client applications can use it to verify the identity of a subject (usually a user) based on the authentication performed by an authorization Server. It also provides basic profileinformation.O
AUTHENTICATION
Authentication is the process of identifying an individual e.g. using a username and password. This basically involves checking whether a user exists and determining who this user is i.e. associating credentials with an identity. Or in other words authentication answers the question “who one is”. OAuth is a specification for authorization and is not an authentication protocol but is used as a basis for authentication protocols like OpenID Connect.AUTHORIZATION
Authorization is the process of giving a subject permissions to access resources in a certain way.OAUTH 2.0 ROLES
OAuth defines the following roles:* Resource Owner
* Client Application* Resource Server
* Authorization ServerRESOURCE OWNER
The resource owner is an entity which can grant a client application a scoped access to a resource. It can be a person (usually the end-user) but can also be a machine.CLIENT APPLICATION
A client application is an application which accesses protected resources on the behalf of the resource owner.RESOURCE SERVER
The resource server manages access to a protected resource, allowing access based on access tokens. It is also often called an API server. The protected resources can e.g. be the profile or personal information of a user. AUTHORIZATION SERVER The authorization server issues access tokens to authenticated client applications when permissions for the access are granted by the resource owner. This is the “OAuth2” server. OAUTH 2.0 ROLE INTERACTIONSTOKENS
There are 3 types of tokens used when working with OAuth2 and OpenID Connect. Additionally, an authorization code is also defined. * The ID token is defined in OpenID Connect on top of the tokensdefined in OAuth2
* The access token is the main token defined in OAuth2 * The refresh token is used, well, to refresh a token * The authorization code is not a token in itself but can be used toget an access token
ID TOKENS
ID Tokens are JSON Web Tokent (JWT) introduced by OpenID Connect. These tokens identify a user and contain user’s authentication information. They contain three parts:* a header
* a body
* a signature
In the token, each of these parts is encoded using Base64Url and concatenated using a “.” (dot) between them: > Base64Url(header) + “.” + Base64Url(body) + “.” > + Base64Url(signature) The body of the token contains a series of claims which provide data about the subject being identified by the token. The OpenID Connect specification doesn’t specify which claims have to be present in which context but does define “standard” claims (with registered claim names) and allows the use of custom claims. The registered claimnames are:
* iss: it’s the issuer of the token. * sub: this claim identifies the subject for which the token was issued. It is at least unique within the scope of an issuer. * aud: this claim identifies the audience for this token. This is the intended recipient(s) for this token. If an entity is processing this token does not identify itself as part of this audience, the token will be rejected. * exp: this is the expiration time of the token. An entity processing this token should reject it once the expiration time isreached.
* nbf: this is the “not before” claim i.e. it defines at which point in time this token will be valid from. An entity processing this token before this point in time should reject it. * jti: this is an identifier for this particular token which should be unique per issuers and only have a low probably of not being uniqueglobally.
Some claims are always added to the ID token by the authentication server and some claims depend on the scopes requested by the entity requesting the authentication. Since the ID tokens contain privacy relevant data about subjects being identified, they should be kept confidential and access tokens should rather be used to access resources i.e. use the ID tokens to identify subjects and get data/metadata regarding the subject and access tokens to access resources / APIs. This is how an ID token could look like:{
"https://benohead.com/country": "Germany", "https://benohead.com/timezone": "Europe/Berlin", "email": "henri.benoit@gmail.com", "email_verified": true, "iss": "https://auth.benohead.com/", "sub": "5b1789917b944931f4021e61", "aud": "q580zCRvynSeIg3uXCChcSRlYtNKSUPe","iat": 1530800423,
"exp": 1530836423
}
ACCESS TOKENS
Access tokens allow a client application to access a protected resource and defines the scope of this allowed access. This token is provided by the client application to the resource server when accessing the resource e.g. as an HTTP header. Just like the ID token, the access token has a limited lifetime which is defined when the authorization server issues the token to the client application. Since it allows access to protected resources, it must be kept confidential as much as possible although this is not always possible especially when a web browser is involved. This is how an access token could look like:{
"iss": "https://auth.benohead.com/", "sub": "5b3cd37722c8f80eecd338e5", "aud": "https://benohead/api/dummy/","iat": 1530802106,
"exp": 1530888506,
"scope": "read update delete create"}
Note that in case the authorization server is also the resource provider (so if the audience matches the authorization server), you might also get an opaque access token which is just a string without any further meaning and which cannot be decoded. The authorization server can then map this string to permission on its own protectedresources.
REFRESH TOKENS
Refresh Token are tokens containing information required to obtain a new ID token or access token. It is usually used to get a new token after the previous one expires. It is usually more secure to have short lived access tokens combined with refresh tokens, since it allows the authorization server to refuse to issue a new access token based on the refresh token in case the token has been compromised but still allow renewing the token in case access to a resource is required for a longer time. Without refresh token (and with long lived access tokens) a resource provider would need to query the authorization server to see whether the long lived access token is still valid. You can skip it when using short lived access tokens. As an alternative to using refresh tokens, you could get a new access token with credentials every time a short lived access token expires. But there has a drawback: If you get the access token with user credentials (additionally to client credentials), you will need these user credentials every time your token expires (while you wouldn’t need the user credentials, just the client credentials, when using arefresh token).
AUTHORIZATION CODES
Authorization codes are codes returned to unsecure clients. These client can then exchange them with an access and/or ID token in a moresecure way.
They are used in the Authorization Code Grant Flow which is a flow where the client is typically a browser which receives an authorization code from the authorization server and sends this to the web application which then interacts with the authorization server in the back-end to exchange the authorization code for an access token, a refresh token and/or ID token. SCOPES AND AUDIENCES Scopes and audiences are used to handle multiple resource servers and multiple types of access permissions.AUDIENCE
The JWT aud (Audience) Claim identifies the intended recipients of the token i.e. it allows an authorization server to issue tokens that are only valid for certain purposes. An audience claim can either contain a list of strings (i.e. multiple audiences) or it can be a single string (i.e. there is only one intended audience). It does not matter if an audience value is a URL or some other application specific string. Each recipient of such a token must validate that the audience specified in the token matches its own audience name. It must then reject any token that does not contain its own audience name in the intended audience. The authorization server which issues the token can only validate whether a token for this audience can be issued. It is the responsibility is the resource server to determine whether the token should be used or not. A resource server may choose to ignore the audience claim and accept any valid token. So the audience claim is only useful if you want to issue tokens with different purposes (i.e. intended audiences) and if at least some of the APIs (resource servers) you are using are validating the audienceclaim.
SCOPES
Scopes provide a way to limit the access to functionality provided by the resource servers. The client can request scopes to be provided in the issued access token. The authorization server can provide all requested scopes, some of them or even additional ones based on its internal rules/policies. The provided scopes are written in the scope claim in the access token. So they basically act as permissions. Authorization servers also use them when getting the consent from the user (i.e. ask the user whether he really wants to provide the client application access to thesespecific scopes).
When the client then uses the issued access token to request access to a protected resource, the resource server will validate that the type of resource and the type of access match the scopes contained in theaccess token.
E.g. if your access token contains the scope claim “read:posts read:comments write:comments”, the resource server would allow an application presenting this token to have read access to the posts and read and write comments but not to create a new post. OPENID CONNECT SCOPES The following scopes are defined in OpenID Connect: * openid: this is the basic OpenID scope requesting to return the sub claim uniquely identifying the user and which can be used in combination with the scope values below. * profile: requests the authorization server to provide access to the user’s profile claims: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at. * email: requests the authorization server to provide access to the email and email_verified claims. * address: requests the authorization server to provide access tothe address claim.
* phone: requests the authorization server to provide access to the phone_number and phone_number_verified claims. OPENID CONNECT ENDPOINTS OpenID Connect defines 2 endpoints which can be used to request one or more of the token types described above: * The Authorization Endpoint is usually an endpoint accessible with the URLto:
* get authenticated by any supported method e.g. with a username and password, an existing session cookie or a federated identity provider such as a social login, SAML provider or ADFS integrated system * issue a token to the client application (or deny it). Optionally, it will request a user consent (or issue a consent implicitly by usingan internal policy)
The type of token being issued depends on the requested response type.THE TOKEN ENDPOINT
The token endpoint can exchange a grant (e.g. an authorization codeprovided by the authorization endpoint) for a token. The grant supported as input are usually: * An authorization code * Client credentials i.e. a client ID and a client secret * A username and password* A refresh token
THE USERINFO ENDPOINT The UserInfo endpoint returns claims about the authenticated user. This is an OAuth 2.0 protected resource so you need to provide an access token to access it. Here is a sample response from this endpoint:{
"sub": "1761101158623", "name": "Henri Benoit", "given_name": "Henri", "family_name": "Benoit", "preferred_username": "benohead", "email": "henri.benoit@gmail.com", "picture": "https://secure.gravatar.com/avatar/bde998b4b8e4b4fb259d80b5ac05d63d"}
OPENID CONNECT RESPONSE TYPES OpenID Connect defines an additional URL parameter called response_type. With this parameter, you can request different types of tokens to be returned. You can combine them by separating them by a space e.g. response_type=code id_token token. * id_token: if this response type is specified, the authorization server will return an ID token * token: if this response type is specified, the authorization server will return an access token * code: if this response type is specified, the authorization server will return an authorization code RESPONSE TYPE: CODE ID_TOKEN TOKEN When using this response type, the endpoints will issue the followingtokens:
ENDPOINT
ID TOKEN
ACCESS TOKEN
AUTHORIZATION CODE
Authorization
Yes
Yes
Yes
Token
Yes
Yes
No
Note that the Token endpoint will never return an authorization code since it is an input for the token endpoint when the authorizationcode grant is used.
RESPONSE TYPE: ID_TOKEN TOKEN When using this response type, the endpoints will issue the followingtokens:
ENDPOINT
ID TOKEN
ACCESS TOKEN
AUTHORIZATION CODE
Authorization
Yes
Yes
No
Token
Not used
Not used
Not used
Note that the Token endpoint is not used in such cases. RESPONSE TYPE: CODE ID_TOKEN When using this response type, the endpoints will issue the followingtokens:
ENDPOINT
ID TOKEN
ACCESS TOKEN
AUTHORIZATION CODE
Authorization
Yes
No
Yes
Token
Yes
Yes
No
Note that the Token endpoint will never return an authorization code since it is an input for the token endpoint when the authorizationcode grant is used.
RESPONSE TYPE: CODE TOKEN When using this response type, the endpoints will issue the followingtokens:
ENDPOINT
ID TOKEN
ACCESS TOKEN
AUTHORIZATION CODE
Authorization
No
Yes
Yes
Token
Yes/No
Yes
No
The token endpoint will only return an ID token if scope openid isrequested.
Note that the Token endpoint will never return an authorization code since it is an input for the token endpoint when the authorizationcode grant is used.
RESPONSE TYPE: ID_TOKEN When using this response type, the endpoints will issue the followingtokens:
ENDPOINT
ID TOKEN
ACCESS TOKEN
AUTHORIZATION CODE
Authorization
Yes
No
No
Token
Not used
Not used
Not used
Note that the Token endpoint is not used in such cases.RESPONSE TYPE: CODE
When using this response type, the endpoints will issue the followingtokens:
ENDPOINT
ID TOKEN
ACCESS TOKEN
AUTHORIZATION CODE
Authorization
No
No
Yes
Token
Yes/No
Yes
No
The token endpoint will only return an ID token if scope openid isrequested.
Note that the Token endpoint will never return an authorization code since it is an input for the token endpoint when the authorizationcode grant is used.
RESPONSE TYPE: TOKEN When using this response type, the endpoints will issue the followingtokens:
ENDPOINT
ID TOKEN
ACCESS TOKEN
AUTHORIZATION CODE
Authorization
No
Yes
No
Token
Not used
Not used
Not used
Note that the Token endpoint is not used in such cases. This scenario basically maps to the OAuth2 Implicit Grant Flow. OAUTH 2.0 GRANT FLOWSGRANT TYPES
A grant type in OAuth 2.0 refers to the way an application gets an access token. OAuth 2.0 defines several grant types: * Authorization Code* Implicit
* Password
* Client Credentials* Device Code
* Refresh Token
Extensions can also define new grant types. Each grant type maps to a different use case. E.g. using a native application, a web application, single page applications, machine-to-machineapplications…
WHICH FLOW SHOULD I USE ? Depending on which type of application you are developping and your ability to open a browser window or store client secrets securely, you will choose one of the flows above.APPLICATION TYPE
GRANT FLOW TYPE
Web Server Application Authorization Code Grant Single Page ApplicationImplicit Grant
Authorization Code Grant with public client Backend Server Application Client Credentials GrantNative Application
Authorization Code Grant with PKCE Authorization Code Grant with public client Native Application with no Browser Window Resource Owner Password Credential Grant Note that when you have a native application without the possibility to open a browser window your only solution is to use the password grant but this solution is still not ideal since this forces the user to enter his/her credentials in your application. So this requires some level of trust from the user. AUTHORIZATION CODE GRANT FLOW The Authorization Code grant type is used by web and mobile apps. It can only be used if the client application is able to open a web browser. It is considered more secure than the implicit grant flow because it doesn’t provide the access token directly in a callback URL parameter but provides a code which can then be exchanged with an access token from a web server or a native app. You can see the authorization code flow in action on theOAuth playground
. The
corresponsing OpenID Connect flow (so involving an ID token) can also be checked on the OAuth playground.
This flow is mainly aimed at web application running on a server where the backend can act as a confidential client i.e. can keep both the client secret and the issues access token secure. So the client identity can be securely assessed and the access token is only shared between the autorization server, the backend of the web application and the resource server. With single page application or other javascript heavy application or native application installed on a desktop computer or a mobile device, it is not possible to keep the client secret secure on the client side. And if such applications have no control on a server side component or this component is not appropriate for taking over the role of the client application in OAuth2 flows, they are consideredpublic client.
When such a public client use the Authorization Code Grant, they cannot authenticate themselves as a client but can still authenticate the user. So the capabilities of the authorization server are somewhat limited since it cannot control which applications are allowed to get an access token in the name of the resource owner. Actually the authorization server cannot even make sure that the application exchanging the authorization code for an access token is actually the same application which got the authorization code. This is a much bigger issue since anyone getting hold of the authorization code could go to the authorization server and get an access token pretending to be the application which got the code. To mitigate this risk, you can use a Proof Key for Code Exchange. This basically just means that when request the authentication code, you provide a secret called “code verifier” that you generate on the fly and use only in the scope of the authorization flow. The authorization server will associate the code verifier to the returned authorization code (it will not return it together with the code). When the application then wants to exchange the code for an access token, it also provides the code verifier which can be checked by the authorization server before returning an access token. You can also see the authorization code flow with PKCE in action on the OAuth playground.
IMPLICIT GRANT FLOW
The implicit grant flow is a flow where the authorization server directly returns an access token in a URL fragment. Unlike the Authorization Code Grant Flow it doesn’t the client application to exchange an authorization code for a token. Originally, it was the recommended “best practice” for all browser based apps. This flow is now mostly used in SPA (Single Page Applications – JavaScript application running in the browser). For other server based web application, you would rather use the Authorization Code Grant Flow. You can see the implicit flow in action on the OAuth playground.
PASSWORD CREDENTIAL GRANT FLOW The password grant is probably the easiest (and least secure) grant type. In this flow, the application needs to know the user credentials and pass them to the authorization server. It is recommended to avoid this flow as much as possible. The main issue bing that the client needs to know you credentials. Imagine you want to allow the great benohead.com app to get your name from Facebook but you have to give it your password and trust the app will not start friending random strangers or posting inappropriate messages or just shut you out by changing your password.__
__
__
Google +
__
Connect 1 Comment
R: LIBGFORTRAN – LIBRARY NOT LOADED Posted on May 29, 2018by hb
If you get the following error message after installing R on your mac:$ R
dyld: Library not loaded: /usr/local/lib/gcc/5/libgfortran.3.dylib Referenced from: /usr/local/Cellar/r/3.2.0_1/R.framework/Versions/3.2/Resources/lib/libR.dylib Reason: image not foundTrace/BPT trap: 5
You’ll need to reinstall gcc with the –with-fortran option: brew reinstall gcc5 --with-fortran__
__
__
Google +
__
Posted in Mac , R
Leave a comment
ANGULARJS AND KENDO UI: WATCHERS FOR GRID AND TREE LIST Posted on May 29, 2018by
hb
When you use the Kendo UI Grid or Tree List widgets in an AngularJS application, you will probably notice that with long grids/lists or with many columns, you’ll end up having quite a few watchers created (basically one watcher per cell). Unfortunately, it is not (yet) possible to use one time binding. The AngularJS documentation recommends keeping the number of watches under 2000 in order not to hurt the application performance (because it otherwise creates a high load during digest cycles). The reason why so many watches are created is that the Kendo UI directives compile (using $compile) all cells so that you can use angular expression and directives in you column templates. Disclaimer: All the instructions below only make sense if you do not need two way binding in your grid or tree list rows. If you do then you actually need these watchers. Currently, the only way to prevent this is to initialize the Kendo Grid (or Tree List) widgets in you controller instead of using the Kendo directives. i.e. replacing this:id="treelist"
k-options="treelistKendoOptions" k-scope-field="treelistScope" k-columns="vm.treeListColumns" k-auto-bind="false">
id="treelist"
k-options="treelistKendoOptions" k-scope-field="treelistScope" k-columns="vm.treeListColumns" k-auto-bind="false">By a simple div:
And creating the tree list (or the grid) in you controller: $("#treelist").kendoTreeList($scope.treelistKendoOptions); Additionally, you’ll have to replace attributes you had in your HTML code when using the directive by option or additional code. In my case, I had to move k-auto-bind to the auto-bind property in theoptions:
$scope.treelistKendoOptions = {...
autoBind: false,
...
};
Another attribute we were using is k-scope-field. This attribute defines a scope variable to which the Grid or Tree List should be bound. You can then call methods of the widget in your controller. The same can also be achieved when instantiating the widget from yourcontroller:
$("#treelist").kendoTreeList($scope.treelistKendoOptions); $scope.treelistScope = $("#treelist").data("kendoTreeList"); Of course, if you use a Grid and not a Tree List, you’d use kendoGrid instead of kendoTreeList. Once you’ve done this, you’ll see the number of watchers has greatly reduce. But you might also see that the contents of some columns are broken. This basically happens whenever you use AngularJS expression (e.g. using some methods on the scope) in you columntemplate e.g.:
template: "{{ versionFormat(dataItem.Version) }} Since we’re not in the Angular world anymore, the templates are not compiled anymore (that’s after all that’s what we wanted to prevent). So you’ll need to add the logic you had in the template to the method defined as data source. In my example above, I’d call versionFormat for every row and replace dataItem.Version by the outputvalue.
__
__
__
Google +
__
Posted in AngularJS
,
JavaScript
Leave a comment
IDX10638: CANNOT CREATED THE SIGNATUREPROVIDER, ‘KEY.HASPRIVATEKEY’ IS FALSE, CANNOT CREATE SIGNATURES. KEY: MICROSOFT.IDENTITYMODEL.TOKENS.RSASECURITYKEY. Posted on May 29, 2018by hb
After updating the Microsoft.IdentityModel.Tokens library we were getting the following error message when creating JWT tokens: > System.InvalidOperationException > HResult=0x80131509 > Message=IDX10638: Cannot created the SignatureProvider, > ‘key.HasPrivateKey’ is false, cannot create signatures. Key: > Microsoft.IdentityModel.Tokens.RsaSecurityKey. > Source=Microsoft.IdentityModel.Tokens> StackTrace:
> at
> Microsoft.IdentityModel.Tokens.AsymmetricSignatureProvider..ctor(SecurityKey > key, String algorithm, Boolean willCreateSignatures)> at
> Microsoft.IdentityModel.Tokens.CryptoProviderFactory.CreateSignatureProvider(SecurityKey > key, String algorithm, Boolean willCreateSignatures)> at
> Microsoft.IdentityModel.Tokens.CryptoProviderFactory.CreateForSigning(SecurityKey > key, String algorithm)> at
> System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.CreateEncodedSignature(String > input, SigningCredentials signingCredentials)> at
> System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.WriteToken(SecurityToken> token)
The code where this happened looked like this and was working finebefore the update:
var buffer = Convert.FromBase64String(Base64Cert); var signingCertificate = new X509Certificate2(buffer, CertificatePassword); var identity = new ClaimsIdentity(Claims); var data = new AuthenticationTicket(identity, null); if (signingCertificate.PrivateKey is RSACryptoServiceProvider rsaProvider){
var key = new RsaSecurityKey(rsaProvider); var signingCredentials = new SigningCredentials(key, SecurityAlgorithms.RsaSha256Signature); var token = new JwtSecurityToken( issuer: TokenIssuer, audience: TokenAudience, claims: data.Identity.Claims, notBefore: DateTime.UtcNow, expires: DateTime.UtcNow.AddMinutes(TokenValidityInMinutes), signingCredentials: signingCredentials);
var tokenString = new JwtSecurityTokenHandler().WriteToken(token); Console.WriteLine(tokenString);}
else
{
Console.Error.WriteLine("signingCertificate.PrivateKey is not an RSACryptoServiceProvider");}
Debugging the code, I saw that signingCertificate.HasPrivateKey was true but key.HasPrivateKey was false In order to solve it, two small changes were required: * Add a keyStorageFlags parameter to the X509Certificate2 constructor so that the imported keys are marked as exportable * Use the ExportParameters method to retrieve the raw RSA key in the form of an RSAParameters structure including private parameters. So using the following code worked without exception: var buffer = Convert.FromBase64String(Base64Cert); var signingCertificate = new X509Certificate2(buffer, CertificatePassword, X509KeyStorageFlags.Exportable); var identity = new ClaimsIdentity(Claims); var data = new AuthenticationTicket(identity, null); if (signingCertificate.PrivateKey is RSACryptoServiceProvider rsaProvider){
var key = new RsaSecurityKey(rsaProvider.ExportParameters(true)); var signingCredentials = new SigningCredentials(key, SecurityAlgorithms.RsaSha256Signature); var token = new JwtSecurityToken( issuer: TokenIssuer, audience: TokenAudience, claims: data.Identity.Claims, notBefore: DateTime.UtcNow, expires: DateTime.UtcNow.AddMinutes(TokenValidityInMinutes), signingCredentials: signingCredentials);
var tokenString = new JwtSecurityTokenHandler().WriteToken(token); Console.WriteLine(tokenString);}
else
{
Console.Error.WriteLine("signingCertificate.PrivateKey is not an RSACryptoServiceProvider");}
__
__
__
Google +
__
Posted in CSharp ,
Programming Leave acomment
IS NULL A VALID JSON TEXT ? Posted on January 15, 2018May 29, 2018by hb
Recently I was working on an issue where a service would return null when called with some parameters and the consuming service would have an issue, because the response read from the HTTP response stream would be a string containing the 4 characters “null” and only had a check whether the string was null and if not was using a JSON converter to parse the JSON text which would result in an exception being thrown. The question we were discussing here is what should be the JSON representation of a null object.WHAT IS JSON ?
JavaScript Object Notation (JSON) is a lightweight, language independent text format for the serialization and exchange of structured data. It is derived from the object literals defined in the ECMAScript Programming Language Standard and defines a small set of formatting rules for the portable representation of structured data. JSON is described in a few standard documents: * RFC 4627: The application/json Media Type for JavaScript Object Notation (JSON) –> Made obsolete after the publication of RFC 7159 * RFC 7159: The JavaScript Object Notation (JSON) Data InterchangeFormat
* ECMA-404: The JSON Data Interchange Syntax JSON TEXT VS. JSON VALUE A JSON text is a sequence of tokens representing structured data transmitted as a string. A JSON value is be an object, array, number, or string, or one of the three literal names: false, null or true. In RFC 4627, a JSON text was defined as serialized object or array. An JSON object value having to start and end with curly brackets and a JSON array value having to start and end with square brackets. This effectively meant that “null” was not a valid JSON text. But even in RFC 4627, null was a valid JSON value.CHANGES IN RFC 7159
RFC 7159 was published in March 2014 and updates RFC 4627. The goal of this update was to remove inconsistencies with other specifications of JSON and highlight practices that can lead to interoperability problems. One of the changes in RFC 7159 is that a JSON text is not defined as being an object or an array anymore but rather as being aserialized value.
This means that with RFC 7159, “null” (as well as “true” and “false”) becomes a valid JSON text. So the JSON text serialized value of a null object is indeed “null”. Unfortunately, not all JSON parsers / deserializers support parsing the string “null”. PARSING NULL WITH JSON.NET When using JSON.Net (Newtonsoft.Json), there are two ways to deserialize a JSON text: * JObject.parse: this returns a JObject which allows you to work with JSON results which structure might not be completely known. * JsonConvert.DeserializeObject: this is always to deserialize the JSON text to an instance of a defined class. JObject.parse unfortunately throws an exception when trying to parse “null” (JObject.Parse(“null”)): > Newtonsoft.Json.JsonReaderException: ‘Error reading JObject from > JsonReader. Current JsonReader item is not an object: Null. Path > ”, line 1, position 4.’ But if you do not have a class corresponding to the JSON text you’re deserializing, you can either use “object” as type when calling JsonConvert.DeserializeObject or use the overload withoutgenerics:
JsonConvert.DeserializeObjectDetails
Copyright © 2024 ArchiveBay.com. All rights reserved. Terms of Use | Privacy Policy | DMCA | 2021 | Feedback | Advertising | RSS 2.0