This chapter describes the details of data types.
The listed below are Authlete's constant values that correspond to the values of application_type property described in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
OpenID Connect Dynamic Client Registration 1.0 imposes additional requirements on redirect URIs base on the application type. The following description about application_type is an excerpt from the specification.
OPTIONAL. Kind of the application. The default, if omitted, is web. The defined values are native or web. Web Clients using the OAuth Implicit Grant Type MUST only register URLs using the https scheme as redirect_uris; they MUST NOT use localhost as the hostname. Native Clients MUST only register redirect_uris using custom URI schemes or URLs using the http: scheme with localhost as the hostname. Authorization Servers MAY place additional constraints on Native Clients. Authorization Servers MAY reject Redirection URI values using the http scheme, other than the localhost case for Native Clients. The Authorization Server MUST verify that all the registered redirect_uris conform to these constraints. This prevents sharing a Client ID across different types of Clients.
The description above says "The default, if omitted, is web." However, Authlete allows the applicationType property of Client to be null. It is because Authlete does not think it is appropriate to force all OAuth 2.0 clients to comply with the new requirements.
The listed below are Authlete's constant values that correspond to the claim types described in OpenID Connect Core 1.0, 5.6. Claim Types. The supportedClaimTypes property of Service is a string array containing values listed below.
Note that, however, currently Authlete does not provide any API to help implementations for AGGREGATED and DISTRIBUTED.
The table below lists top-level properties of the JSON object which represents a client application.
The sequential number of the client application. The value of this property is assigned by Authlete. Even if the property has a value in a /client/create request or a /client/update request, it is ignored.
The sequential number of the service of the client application. The value of this property is assigned by Authlete. Even if the property has a value in a /client/create request or a /client/update request, it is ignored.
The developer of the client application. It consists of at most 100 ASCII letters. This property must not be null.
The client ID. The value of this property is assigned by Authlete. Even if the property has a value in a /client/create request or a /client/update request, it is ignored.
The client secret. A random 512-bit value encoded by base64url (86 letters). The value of this property is assigned by Authlete. Even if the property has a value in a /client/create request or a /client/update request, it is ignored.
Note that Authlete issues a client secret even to a "public" client application, but the client application should not use the client secret unless it changes its client type to "confidential". That is, a public client application should behave as if it had not been issued a client secret. To be specific, a token request from a public client of Authlete should not come along with a client secret although RFC 6749, 3.2.1. Client Authentication says as follows.
Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in Section 2.3 when making requests to the token endpoint.
The client type, either CONFIDENTIAL or PUBLIC. See RFC 6749, 2.1. Client Types for details.
If clientType in a /client/create request or a /client/update request is null, PUBLIC is used.
Redirect URIs that the client application uses to receive a response from the authorization endpoint. Requirements for a redirect URI are as follows.
Must be an absolute URI.
Must not have a fragment component.
The scheme of the redirect URI used for Implicit Grant by a client application whose application type is "web" must be https. This is checked at runtime by Authlete.
The hostname of the redirect URI used for Implicit Grant by a client application whose application type is "web" must not be localhost. This is checked at runtime by Authlete.
The scheme of the redirect URI used by a client application whose application type is "native" must be either (1) a custom scheme or (2) http, which is allowed only when the hostname part is localhost. This is checked at runtime by Authlete.
Must consist of printable ASCII letters only.
Must not exceed 200 letters.
Note that Authlete allows the application type to be null. In other words, a client application does not have to choose "web" or "native" as its application type. If the application type is null, the requirements by OpenID Connect are not checked at runtime.
An authorization request from a client application which has not registered any redirect URI fails unless at least all the following conditions are satisfied.
The client type of the client application is "confidential".
The value of response_type request parameter is code.
The authorization request has the redirect_uri request parameter.
The value of scope request parameter does not contain openid.
RFC 6749 allows partial match of redirect URI under some conditions (see RFC 6749, 3.1.2.2. Registration Requirements for details), but OpenID Connect requires exact match.
A string array of response types which the client application declares that it will restrict itself to using. This property corresponds to response_types in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
If responseTypes in a /client/create request or a /client/update request is null, an array containing just CODE is used.
A string array of grant types which the client application declares that it will restrict itself to using. This property corresponds to grant_types in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
If grantTypes in a /client/create request or a /client/update request is null, an array containing just AUTHORIZATION_CODE is used.
The application type. WEB, NATIVE or null. The value of this property affects the validation steps for a redirect URI. See the description about redirectUris property above.
This property corresponds to application_type in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
An array of email addresses of people responsible for the client application. Each element must consist of printable ASCII letters only and its length must not exceed 100.
This property corresponds to contacts in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The name of the client application. At most 100 unicode letters.
If clientName in a /client/create request or a /client/update request is null, the client ID is used.
This property corresponds to client_name in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Client names with language tags. If the client application has different names for different languages, this property can be used to register the names.
The URL pointing to the logo image of the client application. The URL must consist of printable ASCII letters only and its length must not exceed 200.
This property corresponds to logo_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Logo image URLs with language tags. If the client application has different logo images for different languages, this property can be used to register URLs of the images.
The URL pointing to the home page of the client application. The URL must consist of printable ASCII letters only and its length must not exceed 200.
This property corresponds to client_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
Home page URLs with language tags. If the client application has different home pages for different languages, this property can be used to register the URLs.
The URL pointing to the page which describes the policy as to how end-users' profile data are used. The URL must consist of printable ASCII letters only and its length must not exceed 200.
This property corresponds to policy_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
URLs of policy pages with language tags. If the client application has different policy pages for different languages, this property can be used to register the URLs.
The URL pointing to the "Terms Of Service" page. The URL must consist of printable ASCII letters only and its length must not exceed 200.
This property corresponds to tos_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
URLs of "Terms Of Service" pages with language tags. If the client application has different "Terms Of Service" pages for different languages, this property can be used to register the URLs.
The URL pointing to the JWK Set of the client application. The URL must consist of printable ASCII letters only and its length must not exceed 200. The content pointed to by the URL must be JSON which complies with the format described in "JSON Web Key (JWK), 5. JSON Web Key Set (JWK Set) Format". Of course, the JWK Set must not include private keys of the client application.
If the client application requests encryption for ID tokens (from the authorization/token/userinfo endpoints) and/or signs request objects, it must make available its JWK Set containing public keys for the encryption and/or the signature at the URL of jwksUri. The service (Authlete) fetches the JWK Set from the URL as necessary.
OpenID Connect Dynamic Client Registration 1.0 says that jwks must not be used when the client can use jwks_uri, but Authlete allows both properties to be registered at the same time. However, Authlete does not use the content of jwks when jwksUri is registered.
This property corresponds to jwks_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The content of the JWK Set of the client application. The format is described in "JSON Web Key (JWK), 5. JSON Web Key Set (JWK Set) Format". Of course, the JWK Set must not include private keys of the client application.
This property corresponds to jwks in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The sector identifier which is a URL starting with https. The URL must consist of printable ASCII letters only and its length must not exceed 200.This URL is used by the service to calculate pairwise subject values. See OpenID Connect Core 1.0, 8.1. Pairwise Identifier Algorithm. Note that, however, Authlete does not support pairwise yet.
This property corresponds to sector_identifier_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The subject type that the client application requests. Either PUBLIC or PAIRWISE. the default value is PUBLIC. Details about the subject type are described in OpenID Connect Core 1.0, 8. Subjct Identifier Types.
Because Authlete's implementation for PAIRWISE is not finished yet, even if subjectType configuration parameter of the client application is PAIRWISE, Authlete behaves as if it were PUBLIC.
This property corresponds to subject_type in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The value of alg header parameter of JWS that the client application requires the service to use for signing an ID token. One of the values listed in JWS Algorithm. The default value is RS256.
NONE may be specified, but in that case, the client application cannot obtain an ID token from the service. That is, an authorization request requesting an ID token fails.
This property corresponds to id_token_signed_response_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The value of alg header parameter of JWE that the client application requires the service to use for encrypting an ID token. One of the supported values listed in JWE Algorithm. The default value is null, meaning that an ID token is not encrypted. When idTokenEncryptionEnc is not null, this property must not be null.
If the value of this property indicates an asymmetric encryption algorithm, the client application must make available its JWK Set which contains a public key for encryption at the URL referred to by its jwksUri configuration property.
This property corresponds to id_token_encrypted_response_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The value of enc header parameter of JWE that the client application requires the service to use for encrypting an ID token. One of the values listed in JWE Encryption Algorithm. The default value is (1) A128CBC_HS256 when idTokenEncryptionAlg is not null, or (2) null when idTokenEncryptionAlg is null.
This property corresponds to id_token_encrypted_response_enc in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The value of alg header parameter of JWS that the client application requires the service to use for signing the JWT returned from the user info endpoint. One of the values listed in JWS Algorithm. The default value is null, meaning that the data from the user info endpoint is not signed.
If both userInfoSignAlg and userInfoEncryptionAlg are null, the format of the response from the user info endpoint is a plain JSON (not JWT). Note that null and NONE are different for this property.
This property corresponds to userinfo_signed_response_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The value of alg header parameter of JWE that the client application requires the service to use for encrypting the JWT returned from the user info endpoint. One of the supported values listed in JWE Algorithm. The default value is null, meaning that the data from the user info endpoint is not encrypted. When userInfoEncryptionEnc is not null, this property must not be null.
If both userInfoSignAlg and userInfoEncryptionAlg are null, the format of the response from the user info endpoint is a plain JSON (not JWT).
This property corresponds to userinfo_encrypted_response_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The value of enc header parameter of JWE that the client application requires the service to use for encrypting the JWT returned from the user info endpoint. One of the values listed in JWE Encryption Algorithm. The default value is (1) A128CBC_HS256 when userInfoEncryptionAlg is not null, or (2) null when userInfoEncryptionAlg is null.
This property corresponds to userinfo_encrypted_response_enc in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The value of alg header parameter of JWS that the client application uses for signing a request object. One of the values listed in JWS Algorithm. The default value is null, meaning that the client application may use any algorithm (among those supported by the service) to sign a request object (including none).
If the value of this property is not null, request objects sent from the client application must be signed using the algorithm. Request objects signed by other algorithms are rejected. Note that null and NONE are different for this property.
If the value of this property indicates an asymmetric signing algorithm, the client application must make available its JWK Set which contains a public key for the service to verify the signature of the request object at the URL referred to by its jwksUri configuration property.
This property corresponds to request_object_signing_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The value of alg header parameter of JWE that the client application uses for encrypting a request object. One of the supported values listed in JWE Algorithm. The default value is null. When requestEncryptionEnc is not null, this property must not be null.
Regardless of whether the value of this property is null or not, the client application may and may not encrypt a request object. Furthermore, the client application may use other supported encryption algorithms.
This property corresponds to request_object_encryption_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The value of enc header parameter of JWE that the client application uses for encrypting a request object. One of the values listed in JWE Encryption Algorithm. The default value is (1) A128CBC_HS256 when requestEncryptionAlg is not null, or (2) null when requestEncryptionAlg is null.
This property corresponds to request_object_encryption_enc in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The client authentication method that the client application declares that it uses at the token endpoint. One of the values listed in Client Authentication Method. The default value is CLIENT_SECRET_BASIC.
This property corresponds to token_endpoint_auth_method in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The value of alg header parameter of JWS which is used for client authentication at the token endpoint. One of the values listed in JWS Algorithm except NONE. The default value is null, meaning that the client may sign using any algorithm which is supported by the service. If the value of this property is not null, the client application must use the algorithm.
This property is used only for the two JWT-based client authentication, namely, PRIVATE_KEY_JWT and CLIENT_SECRET_JWT (see Cient Authentication Method). Note that, however, currently Authlete does not provide any API to help implementations for PRIVATE_KEY_JWT and CLIENT_SECRET_JWT.
This property corresponds to token_endpoint_auth_signing_alg in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The default maximum authentication age in seconds. This value is used when an authorization request from the client application does not have max_age request parameter.
This property corresponds to default_max_age in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The default ACRs (Authentication Context Class References). This value is used when an authorization request from the client application has neither acr_values request parameter nor acr claim in claims request parameter.
Each element must consist of printable ASCII letters only and its length must not exceed 200.
true if the client application requires the auth_time claim to be in an ID token. Regardless of the value of this property, Authlete embeds the auth_time claim when authTime parameter in the /auth/authorization/issue request is not 0 and does not do it when authTime is 0.
This property corresponds to require_auth_time in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
The URL which a third party can use to initiate a login by the client application. The URL must start with https and consist of ASCII letters only. Its length must not exceed 200.
This property corresponds to initiate_login_uri in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata.
An array of URLs each of which points to a request object. Each URL must consist of printable ASCII letters only and its length must not exceed 200.
Authlete requires that URLs used as values for request_uri request parameter be pre-registered. This requestUris property is used for the pre-registration. See OpenID Connect Core 1.0, 6.2. Passing a Request Object by Reference for details.
The description about the client application. At most 200 letters in unicode.
Descriptions about the client application with language tags. If the client application has different descriptions for different languages, this property can be used to register the descriptions.
The time at which this client was created. The value is represented as milliseconds since the UNIX epoch (1970-01-01).
The time at which this client was last modified. The value is represented as milliseconds since the UNIX epoch (1970-01-01).
The table below lists Authlete's constant values that correspond to the client authentication methods at the token endpoint described in OpenID Connect Core 1.0, 9. Client Authentication.
This value corresponds to "none" described in OpenID Connect Core 1.0, 9. Client Authentication.
This value corresponds to "client_secret_basic" described in OpenID Connect Core 1.0, 9. Client Authentication. This is the Basic Authentication based method described in RFC 6749, 2.3. Client Authentication, which authorization servers must support.
This value corresponds to "client_secret_post" described in OpenID Connect Core 1.0, 9. Client Authentication. This is the method using the request body, which is described in RFC 6749, 2.3. Client Authentication.
This value corresponds to "client_secret_jwt" described in OpenID Connect Core 1.0, 9. Client Authentication.
This value corresponds to "private_key_jwt" described in OpenID Connect Core 1.0, 9. Client Authentication.
RFC 6749, 2.3. Client Authentication mentions two means for client authentication. One is Basic Authentication where client credentials are encoded in Authorization header. The other is a means to embed client credentials in the request body in application/x-www-form-urlencoded format. OpenID Connect Core 1.0 adds two JWT-based client authentication methods, namely, client_secret_jwt and private_key_jwt.
The supportedTokenAuthMethods property of Service is a string array containing values listed above. Note that, however, currently Authlete does not provide any API to help implementations for CLIENT_SECRET_JWT and PRIVATE_KEY_JWT.
The listed below are Authlete's constant values that correspond to the client types described in RFC 6749, 2.1. Client Types. The clientType property of Client has either of the values listed below.
The listed below are Authlete's constant values that correspond to the display values described in "OpenID Connect Core 1.0, 3.1.2.1. Authentication Request, display". The supportedDisplays property of Service is a string array containing values listed below.
The table below lists Authlete's constant values that correspond to the values of grant_type request parameter for OAuth 2.0 token endpoint. Among the values listed here, however, implicit cannot be used as a value for grant_type request parameter. It exists only as a value of supportedGrantTypes property of Service and grantTypes property of Client.
This corresponds to "authorization_code" defined in RFC 6749, 4.1.3. Access Token Request for Authorization Code Grant.
This corresponds to "implicit" defined in OpenID Connect Dynamic Client Registration 1.0, 2. Client Metadata for Implicit Grant.
This corresponds to "password" defined in RFC 6749, 4.3.2. Access Token Request for Resource Owner Password Credentials Grant.
This corresponds to "client_credentials" defined in RFC 6749, 4.4.2. Access Token Request for Client Credentials Grant.
This corresponds to "refresh_token" defined in RFC 6749, 6. Refreshing an Access Token.
The listed below are Authlete's constant values that correspond to the values of "alg" header parameter of JSON Web Encryption (JWE), which are described in JSON Web Algorithms (JWA), 4.1. "alg" (Algorithm) Header Parameter Values for JWE.
Currently, Authlete supports RSA1_5, RSA_OAEP, RSA_OAEP_256 and DIR only.
The listed below are Authlete's constant values that correspond to the values of "enc" header parameter of JSON Web Encryption (JWE), which are described in JSON Web Algorithms (JWA), 5.1. "enc" (Encryption Algorithm) Header Parameter Values for JWE.
The listed below are Authlete's constant values that correspond to the values of "alg" header parameter of JSON Web Signature (JWS), which are described in JSON Web Algorithms (JWA), 3.1. "alg" (Algorithm) Header Parameter Values for JWS.
The table below lists Authlete's valid constant values that correspond to response_type request parameter for OAuth 2.0 authorization endpoint. RFC 6749 defines two values, "code" and "token". Other values listed here are added by OAuth 2.0 Multiple Response Type Encding Practices, which is a part of Open ID Connect specification.
The supportedResponseTypes property of Service and the responseTypes property of Client are a string array containing values listed below.
This corresponds to "none" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 4. None Response Type.
This corresponds to "code" defined in RFC 6749, 4.1.1. Authorization Request for Authorization Code Grant.
This corresponds to "token" defined in RFC 6749, 4.2.1. Authorization Request for Implicit Grant.
This corresponds to "id_token" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 3. ID Token Response Type.
This corresponds to "code token" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 5. Definitions of Multiple-Valued Response Type Combinations.
This corresponds to "code id_token" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 5. Definitions of Multiple-Valued Response Type Combinations.
This corresponds to "id_token token" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 5. Definitions of Multiple-Valued Response Type Combinations.
This corresponds to "code id_token token" defined in OAuth 2.0 Multiple Response Type Encoding Practices, 5. Definitions of Multiple-Valued Response Type Combinations.
This is a data structure for a scope which is described in RFC 6749, Access Token Scope. The data structure has properties listed in the following table.
The name of the scope. Letters that can be used for a scope name are %x21, %x23-5B and %x5D-7E. Put simply, they are printable ASCII letters excluding "space (%x20)", "double quotation mark (%x22)" and "backslash (%x5C)". Its length must not exceed 200.
true to mark the scope as default. Scopes marked as default are regarded as requested when an authorization request from a client application does not contain scope request parameter.
OPTIONAL. The description of the scope. It is a unicode string. Its length must not exceed 200.
The table below lists top-level properties of the JSON object which represents a service.
The sequential number of the service. The value of this property is assigned by Authlete. Even if the property has a value in a /service/create request or a /service/update request, it is ignored.
The sequential number of the service owner of the service. The value of this property is assigned by Authlete. Even if the property has a value in a /service/create request or a /service/update request, it is ignored.
The name of the service. It consists of at most 100 unicode letters. This property must not be null.
The API key. The value of this property is assigned by Authlete. Even if the property has a value in a /service/create request or a /service/update request, it is ignored.
The API secret. A random 256-bit value encoded by base64url (43 letters). The value of this property is assigned by Authlete. Even if the property has a value in a /service/create request or a /service/update request, it is ignored.
The issuer identifier of the service. A URL that starts with https:// and has no query or fragment component. For example, https://example.com. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property must not be null.
The value of this property is used as iss claim in an ID token and issuer property in the OpenID Provider Metadata.
The authorization endpoint of the service. A URL that starts with https:// and has no fragment component. For example, https://example.com/auth/authorization. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property must not be null.
The value of this property is used as authorization_endpoint property in the OpenID Provider Metadata.
The token endpoint of the service. A URL that starts with https:// and has not fragment component. For example, https://example.com/auth/token. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property may be null if and only if the service supports only Implicit Grant (= supports response_type=token only).
The value of this property is used as token_endpoint property in the OpenID Provider Metadata.
The revocation endpoint of the service. A URL that starts with https://. For example, https://example.com/auth/revocation. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property may be null if the service does not support the revocation endpoint.
The user info endpoint of the service. A URL that starts with https://. For example, https://example.com/auth/userinfo. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property may be null if the service does not support the user info endpoint.
The value of this property is used as userinfo_endpoint property in the OpenID Provider Metadata.
The URL of the service's JSON Web Key Set document. For example, http://example.com/auth/jwks. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200. This property may be null if and only if the service does not support asymmetric signatures for ID tokens and asymmetric encryption for request objects.
Client applications accesses this URL (1) to get the public key of the service to validate the signature of an ID token issued by the service and (2) to get the public key of the service to encrypt an request object of the client application. See OpenID Connect Core 1.0, 10. Signatures and Encryption for details.
The value of this property is used as jwks_uri property in the OpenID Provider Metadata.
The content of the service's JSON Web Key Set document. If this property is not null in a /service/create request or a /service/update, Authlete hosts the content in the database. This property must not be null and must contain pairs of public/private keys if the service wants to support asymmetric signatures for ID tokens and asymmetric encryption for request objects. See OpenID Connect Core 1.0, 10. Signatures and Encryption for details.
The registration endpoint of the service. A URL that starts with https://. For example, https://example.com/auth/registration. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200.
The value of this property is used as registration_endpoint property in the OpenID Provider Metadata.
Scopes supported by the service. Authlete strongly recommends that the service register at least the following scopes.
A permission to get an ID token of an end-user.
The openid scope appears in "OpenID Connect Core 1.0, 3.1.2.1. Authentication Request, scope". Without this scope, Authlete does not allow response_type request parameter to have values other than code and token.
A permission to get information about name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender birthdate, zoneinfo, locale and updated_at from the user info endpoint.
See OpenID Connect Core 1.0, 5.4. Requesting Claims using Scope Values for details.
A permission to get information about email and email_verified from the user info endpoint.
A permission to get information about address from the user info endpoint.
See OpenID Connect Core 1.0, 5.4. Requesting Claims using Scope Values and 5.1.1. Address Claim for details.
A permission to get information about phone_number and phone_number_verified from the user info endpoint.
A permission to get information from the user info endpoint even when the end-user is not present.
See OpenID Connect Core 1.0, 11. Offline Access for details.
The value of this property is used as scopes_supported property in the OpenID Provider Metadata.
Values of response_type request parameter that the service supports. Valid values are listed in Response Type.
The value of this property is used as response_types_supported property in the OpenID Provider Metadata.
Values of grant_type request parameter that the service supports. Valid values are listed in Grant Type.
The value of this property is used as grant_types_supported property in the OpenID Provider Metadata.
Values of Authentication Context Class References that the service supports.
The value of this property is used as acr_values_supported property in the OpenID Provider Metadata.
Client authentication methods supported by the token endpoint of the service. Valid values are listed in Client Authentication Method. Note that, however, currently Authlete does not provide any API to help implementations for CLIENT_SECRET_JWT and PRIVATE_KEY_JWT.
The value of this property is used as token_endpoint_auth_methods_supports property in the OpenID Provider Metadata.
Values of display request parameter that service supports. Valid values are listed in Display.
The value of this property is used as display_values_supported property in the OpenID Provider Metadata.
Claim types supported by the service. Valid values are listed in Claim Type. Note that, however, currently Authlete does not provide any API to help implementations for AGGREGATED and DISTRIBUTED.
The value of this property is used as claim_types_supported property in the OpenID Provider Metadata.
Claim names that the service supports. The standard claim names listed in OpenID Connect Core 1.0, 5.1. Standard Claim should be supported. The following is the list of standard claims.
The value of this property is used as claims_supported property in the OpenID Provider Metadata.
The service may support its original claim names. See OpenID Connect Core 1.0, 5.1.2. Additional Claims. Note that Authlete requires that original claim names consist of only ASCII letters and its length not exceed 200.
The URL of a page where documents for developers can be found.
The value of this property is used as service_documentation property in the OpenID Provider Metadata.
Claim locales that the service supports. Each element is a language tag defined in RFC 5646. For example, "en-US" and "ja-JP". Authlete requires that each language tag consist of only ASCII letters and its length not exceed 30. See OpenID Connect Core 1.0, 5.2. Languages and Scripts for details.
The value of this property is used as claims_locales_supported property in the OpenID Provider Metadata.
UI locales that the service supports. Each element is a language tag defined in RFC 5646. For example, "en-US" and "ja-JP". Authlete requires that each language tag consist of only ASCII letters and its length not exceed 30.
The value of this property is used as ui_locales_supported property in the OpenID Provider Metadata.
The URL of the "Policy" of the service. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200.
The value of this property is used as op_policy_uri property in the OpenID Provider Metadata.
The URL of the "Terms Of Service" of the service. Authlete requires that the URL consist of only ASCII letters and its length not exceed 200.
The value of this property is used as op_tos_uri property in the OpenID Provider Metadata.
A Web API endpoint for user authentication which is to be prepared on the service side. It must consist of only ASCII characters and its length must not exceed 200.
API key for Basic authentication at the authentication callback endpoint. It must consist of only ASCII characters and its length must not exceed 100.
API secret for Basic authentication at the authentication callback endpoint. It must consist of only ASCII characters and its length must not exceed 100.
SNSes you want to support 'social login' in the UI at the authorization endpoint provided by Authlete. You need to register a client application in each SNS that is set to this parameter and set Authlete server's /api/sns/redirection as the redirection endpoint of the client application.
SNS credentials which Authlete uses to make requests to SNSes. The format is JSON.
The time at which this service was created. The value is represented as milliseconds since the UNIX epoch (1970-01-01).
The time at which this service was last modified. The value is represented as milliseconds since the UNIX epoch (1970-01-01).
A Web API endpoint for developer authentication which is to be prepared on the server side. It must consist of only ASCII characters and its length must not exceed 200.
API key for Basic authentication at the developer authentication callback endpoint. It must consist of only ASCII characters and its length must not exceed 100.
API secret for Basic authentication at the developer authentication callback endpoint. It must consist of only ASCII characters and its length must not exceed 100.
SNSes you want to support 'social login' in the login page of Developer Console provided by Authlete. You need to register a client application in each SNS checked here and set Authlete server's /api/developer/sns/redirection as the redirection endpoint of the client application.
The maximum number of client applications that a developer is allowed to create. 0 means no limit.
The flag to indicate whether the direct authorization endpoint is enabled or not.
If true, the default implementation of the authorization endpoint of this service works. The URL of the endpoint is https://api.authlete.com/api/auth/authorization/direct/service-api-key.
If false, the endpoint returns 404 Not Found. In this case, you have to implement the authorization endpoint by yourself using Authlete's Web APIs such as /api/auth/authorization, /api/auth/authorization/issue and /api/auth/authorization/fail.
The flag to indicate whether the direct token endpoint is enabled or not.
If true, the default implementation of the token endpoint of this service works. The URL of the endpoint is https://api.authlete.com/api/auth/token/direct/service-api-key.
If false, the endpoint returns 404 Not Found. In this case, you have to implement the token endpoint by yourself using Authlete's Web APIs such as /api/auth/token, /api/auth/token/issue and /api/auth/token/fail.
The flag to indicate whether the direct revocation endpoint is enabled or not.
If true, the default implementation of the revocation endpoint (RFC 7009) of this service works. The URL of the endpoint is https://api.authlete.com/api/auth/revocation/direct/service-api-key.
If false, the endpoint returns 404 Not Found. In this case, if you want to provide a revocation endpoint to client applications, you have to implement the endpoint by yourself using Authlete's /api/auth/revocation API.
The flag to indicate whether the direct userinfo endpoint is enabled or not.
If true, the default implementation of the userinfo endpoint of this service works. The URL of the endpoint is https://api.authlete.com/api/auth/userinfo/direct/service-api-key.
If false, the endpoint returns 404 Not Found. In this case, if you want to provide a userinfo endpoint to client applications, you have to implement the endpoint by yourself using Authlete's /api/auth/userinfo API.
The flag to indicate whether the direct jwks endpoint is enabled or not.
If true, the default implementation of the JWK Set endpoint of this service works. The URL of the endpoint is https://api.authlete.com/api/service/jwks/get/direct/service-api-key.
If false, the endpoint returns 404 Not Found. In this case, if you want to provide a JWK Set endpoint to client applications, you have to implement the endpoint by yourself using Authlete's /api/service/jwks/get API.
The flag to indicate whether the number of access tokens per subject (and per client) is at most one or can be more.
If true, an attempt to issue a new access token invalidates existing access tokens that are associated with the same subject and the same client.
Note that, however, attempts by Client Credentials Flow do not invalidate existing access tokens because access tokens issued by Client Credentials Flow are not associated with any end-user's subject. Also note that an attempt by Refresh Token Flow invalidates the coupled access token only and this invalidation is always performed regardless of whether the value of this setting item is true or false.
The flag to indicate whether the use of Proof Key for Code Exchange (PKCE) is always required for authorization requests by Authorization Code Flow.
If true, code_challenge request parameter is always required for authorization requests using Authorization Code Flow.
See RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients) for details about code_challenge request parameter.
The flag to indicate whether a refresh token remains unchanged or gets renewed after its use.
If true, a refresh token used to get a new access token remains valid after its use. Otherwise, if false, a refresh token is invalidated after its use and a new refresh token is issued.
See RFC 6749 6. Refreshing an Access Token, as to how to get a new access token using a refresh token.
The description about the service. It consists of at most 200 unicode letters.
The access token type. This value is used as the value of token_type property in access token responses. If this service complies with RFC 6750, the value of this property should be Bearer.
See RFC 6749 (OAuth 2.0), 7.1. Access Token Types for details.
The duration of access tokens in seconds. This value is used as the value of expires_in property in access token responses. expires_in is defined RFC 6749, 5.1. Successful Response.
The duration of refresh tokens in seconds. The related specifications have no requirements on refresh token duration, but Authlete sets expiration for refresh tokens.
The duration of ID tokens in seconds. This value is used to calculate the value of exp claim in an ID token.
The extra properties associated with the service. The content of the returned array depends on contexts. The type is an array of string. string is a key and string is its value. null may be returned. The predefined service properties are show below.
The number of client applications which belong to this service.
The listed below are Authlete's constant values that correspond to the subject identifier types described in OpenID Connect Core 1.0, 8. Subject Identifier Types.
Note that currently Authlete's implementation for PAIRWISE is not finished, so PAIRWISE behaves in the same way as PUBLIC.
TaggedValue is a generic-purpose data structure to describe a pair of a language tag and a string. This data structure has two members, tag and value as described in the table below.
The language tag part. It must consist of only ASCII letters. Its length must not exceed 30.
The value part. It is a unicode string, but some client properties put more restrictive limitations such as "ASCII only". Its length must not exceed 200.
Some properties of Client such as clientNames and logoUris are represented in this data structure. See OpenID Connect Core 1.0, 5.2. Claims Languages and Scripts for the usage of language tags in OpenID Connect.
Property that consists of a string key and a string value.
This data type is used mainly to represent an extra property that is associated with an access token. Some Authlete APIs (such as /api/auth/token API) accept an array of properties via properties request parameter and associate the properties with an access token.
The flag to indicate whether this property hidden from or visible to client applications.
If true, this property is hidden from client applications. Otherwise, this property is visible to client applications.
See Extra Properties for details.


A bold bar adds edge to a gilded cuff. The modern design is a symbol of strength and power. Inspired by the permanency of a precious bracelet.
This gorgeous rose gold pendant necklace gives you endless fashion possibilities, as it can be dressed up or down to go with anything. When given as a jewellery gift, the infinity necklace tells her that your love is eternal and will last for all time.
You're guaranteed to fall in love with this whimsical love bracelet. The LOVE word-plate adds a romantic touch to the feminine design, and the "O" and "E" are set with sparkling cubic zirconia crystals.
Add a chic finishing touch to the neckline of a top or dress with this sophisticated pendant necklace. The sleek delicate necklace with a round pendant is simple enough to pair with casual outfits, yet elegant enough to pair perfectly with your favorite little black dress. Perfect for wearing alone as well as layering with other delicate necklaces.
Meet the perfect necklace to polish off a V-neck t-shirt, blouse, sweater or dress! The V shaped pendent stands out and adds a modern finishing touch to any outfits.
Simple yet trendy ring featuring double T details.
Delicate double bar ring featuring sparkly crystals details.
Delicate bar bracelet featuring roman numeral and tiny crystal details.
Geometric ring featuring a frame square shape.
Simple yet modern triple chevron ring is your ring stacks must have.
Statement ring featuring roman numeral details. Matching bangle available.
Delicate minimalist ring featuring a wire heart shape.
Modern yet classy Pave H cuff featuring cubic zirconia details.
We can't get enough of this beautiful dainty ring! Made with shimmery druzy stone. Stack on multiples for a fun boho look or keep it simple and chic by itself.
Modern and unique double bar ring with pearl and blue crystal detail.
Modern and unique statement ring featuring pearls and crystal details.
Crystal Claw Ring featuring 4 crystal details.
Simple yet trendy Bar Studs. Comes in gold and silver.
New ear trend - Ear Crawler featuring LOVE script and a little rhinestone. Comes in gold and silver.
Double Cross Ring featuring pave rhinestones.
Beautiful Ear Jackets featuring sparkly crystal mixed with pearls.
Beautiful and classy Ear Jackets featuring 6 faux pearls details. Can be worn as single pearl studs or ear jackets. 1 pair of earrings, 2-way of wearing. Can also mix and match with our other ear jackets.
Cut out hearts ring. Wearing alone or stacking. Available in smaller size for midi ring (knuckle ring).
Sparkly crystal drop earrings featuring zirconia crystal details.
An adorable ring featuring angel's wings with rhinestones.
3 pieces set of rings featuring sparkly crystal in clover, bow and heart shape. Stacking or wear alone.
Cute little fox ring. Adjustable in size.
Cocktail ring featuring faceted stone and rhinestones details.
This beautiful halo ring featuring cushion cut square shape, an elegant timeless piece. Perfect for everyday wear in any occasions. Wearing alone or stacking.
This Crystal Pendant Necklace is perfect for any occasions, ideal for wearing alone as well as layering.
An adorable crystal bow ring featuring heart shape sparkling clear crystals.
Our gold plated jewellery are mostly plated on stainless steel with 14K or 18K gold plating. A few are plated on brass.


text:
The Roman Legions
of Britain
Structure of
a Legion
The Roman Soldier
Focale (scarf)
Braccae (breeches)
& Feminala
Subligaculum (underwear)
Paenula or Sagum (Cloak)
Udones (socks)
Gear, Main Page
Galea (Helmet)
Lorica (Armor)
Scutum (Shield)
Cingulum Militare
(Soldier's Belt)
Roman Weapons
Gladius (Sword)
Pugio (Dagger)
Roman Artillery
A New
Soldier Arrives
A Soldier's Life
Roman Battle
Warfare in Roman times was ugly and shocking in it's ferocity and the injuries sustained. None more so than in the damage caused to flesh and bone by the machines of the Roman artillery. The weapons the Romans had at their disposal were not actually invented by them. They were adaptations of weapons used by the Greeks. The Romans merely took the designs and improved on them, using the materials and knowledge available to them at that time.
Roman artillery came in many shapes and forms, but it was all used with one purpose in mind. To attack enemy strongholds and weaken their defences to make the job of infantry easier. To this end , they used a variety of weapons that we shall be examining in detail.
The British tribes had very limited ways of fighting battles. Their creativity in thinking of new methods of dealing with attacks was virtually non existent. As such they relied upon such tactics as surprise assaults and fortresses built behind man made defences.
The Romans had done their research well and knew of these strategies their opponents employed and though of ways to counter them.
So the Romans developed methods of combating the defences of their enemies. First they would lay down a barrage of artillery fire to soften the enemy ready for the military. When the opposition were suitably weakened, the infantry would enter the battle and complete the job
Even today in conflicts such as the Gulf Wars and Afghanistan, these same methods were used to subdue the enemy forces, ready for the foot soldiers.
The ballista.
In terrain such as found in Britain, the larger catapult and slingshot type weapons were too cumbersome and heavy to transport to a battle site. So the Romans invented a smaller, easily conveyed, effective weapon. The ballista, which was basically a giant crossbow and indeed developed on the same principle of firing iron tipped bolts towards the enemy positions.
This was a smaller weapon than the catapult type of artillery that fired huge rocks into enemy positions and destroyed the walls so the infantry could gain entry. The ballista was used to kill and injure the people within the fort, rather than damage the surrounding walls.
The construction of the ballista was similar to the Roman bow. The flexible arms that projected from each side at the front were made from layers of thin wood strips. These layers were constructed in such a way that the grain of the wood in a layer was at an angle to the layers on either side. If you have ever seen plywood, you will know the principle. These strips were then glued together to form a flexible yet strong weapon. From the end of each end strands of twisted or platted rope hung loosely. This rope would be pulled back by an artillery soldier using a winch fitted to the weapon. Because of the huge forces involved, a winch had to be employed as no human could ever pull back the rope by hand alone.
The rope was then secured by a locking shaft at the back of the ballista. A bolt or large stone was placed in front of the rope and a length of strong cord attached to the shaft was pulled to release the missile.
The ballista came in a range of sizes with arms anywhere from 2ft to 4ft (60cm to 120cm). Using reconstructed small baliistae, a 1 pound (½ kg) missile could be fired at least 300 yards (275m). The larger ballista was capable of hitting a wall up to 550 yards (503m) away. This was far outside the range of enemy bowmen who could only fire the arrows to a distance of about 110 yards (100m)
The ballista was brought to a predetermined distance from the target. It was loaded with a 3ft (100cm) bolt or a large stone and aimed just above the walls. It was then fired with deadly effect.
The projectile would either hit an enemy warrior, or land in the compound impacting on anyone in the way. The speed of the missile was phenomenal. When it arrived at the target it was usually traveling at about 115mph (184kph). Anyone in the way would not have stood a chance. A bolt would have gone straight through a human body or impaled the victim against a wall. Even if it hit a limb, whoever was hit would have been disabled or even had their arm or leg bone shattered. The rocks fired would certainly have taken off a head without any problem. If they hit someone, the effect was horrific with the body ripped apart and the internal organs splattered for yards around.
The repeating ballista
Roman technicians developed the repeating ballista. A cam was used to move a magazine of bolts , one at a time, into position and also tensioned the rope that fired the bolts. This was very much like a Gatling gun used in the American west of the late 19th century. It was a most fearsome weapon, but not so practical as the lesser machine. This was due to the nature of the machine that caused the bolts to land in a close target area. It could not easily be moved a few degrees between shots as the single shot version could.
This Celtic warrior would have been in agony with a ballista bolt lodged in his spine. His torment would have been ended by a Roman sword
This Celt would probably never have known he had been hit by a ballista bolt. Note the lack of cracks around the entry point. Such was the speed of impact, it cut a neat square hole in his skull
The onager (Wild Ass)
This weapon was not as popular in Roman Britain as it was on the continent. This is because it was a very large cumbersome instrument and difficult to transport across the British landscape. Also, it had a much shorter range than the ballista and so had to be deployed closer to the target, often within range of the enemy's archers.
The onager was a base frame with wheels at each cornet. In the middle was a vertical framework with a crossbar at the top. At the bottom was a long beam of wood which was attached at the lower end to a very tightly twisted platted rope. This was to give the spring action to the weapon. At the other end of the arm was a large spoon like container that held the missile, which was normally filled with a heavy rock or masses of stones. The rocks could weigh up to 150lbs (()68kgs) and were used to smash through walls, ramparts and turrets.
In use the onager would have the spoon wound down to ground level and secured by a catch at the bottom. The rock(s) would be loaded and the catch released. The arm would then swing up and hit the crossbar, sending it's deadly cargo towards the enemy position.
Josephus, the writer describes the onager in action.
The momentum of the stones hurled by the engine carried away battlements and knocked off corners of towers. There was a constant thudding of dead bodies as they were thrown one after another from the rampart.
A note: I saw one of these things shot at a Roman Days event. It was crazy dangerous. A HUGE amount of power released and if anything went wrong, you did not want to be near it. I found it way scarier than the 15' high ballista that a reenactor had made (I wonder what ever happened to that?!).
scorpio (Scorpion)
The scorpio or scorpion was type of Roman artillery piece. Also known by the name of the "triggerfish", it was described in detail by Vitruvius. In the progressive evolution of catapults, the next major improvement after the scorpio was the cheiroballistra. A weapon of remarkable precision and power, the scorpio was particularly dreaded by the enemies of the Roman Empire.
The scorpio was a smaller catapult-type weapon, more of a sniper weapon than a siege engine, being operated by only one man. The scorpio was basically a primitive giant crossbow, a "catapult with bolts", probably first invented by the Greeks, then later adopted and used on a larger scale by the Roman legions. This catapult used a system of torsion springs, making it possible to obtain very great power and thus a high speed of ejection for the bolts.
The complexity of construction, adjustment and the great sensitivity to any variation in temperature or moisture limited their use, due to the torsion spring which the Romans referred to as tormenta. Moreover, this type of technology, which disappeared as of the High Middle Ages (with the exception of the Byzantine Empire), reappeared during the First Crusade with a new type of catapult based on a system of slings and counterweights which gave rise to the precision balances for the projection of stone balls or giant crossbows (thanks to the progress made in the field of metallurgy).
The first bolt-shooting catapult on display at the Roman Army Museum is the original Greek design, the scorpio, with a front frame made of wood reinforced with metal plates. It first appears in about 350 BC and may have been invented by Greek engineers working for King Philip II of Macedon, the father of Alexander the Great. It was eventually adopted by the Roman army.
The Roman Army Museum's full-size reconstruction is the most authentic made so far because it is a millimetre accurate reconstruction of an actual frame discovered at Xanten-Wardt in north west Germany in 1999.
Actual Scorpio Minor found in the Rhine River
The Xanten-Wardt frame dates from the middle of the 1st century AD, the time of the Roman invasion of Britain. It is no surprise that the iron heads of bolts from this size of bolt-shooter are found at the Iron Age hillforts of Maiden Castle, Hod Hill and Ham hill, three of the British strongholds captured by Vespasian at the start of the invasion in AD 43. The two bolt heads below are from Hod Hill and are on display in the British Museum.
Reproduction Scorpio and relic bolts
The exact sizes of all other parts, the curved arms, stock and stand, are given in the description by Vitruvius, the engineer appointed in charge of the Roman army's catapults by Emperor Augustus.
This design of bolt-shooter continued in use into the 2nd century AD. Two partially completed parts from the wood frame were discovered in a Roman workshop or store, dated to about AD 140, in the 1999 excavations in front of Carlisle Castle.
During the Roman Republic and early empire eras, 60 scorpio per legion was the standard, or one for every centuria. The scorpio had mainly two functions in a legion: in tended shooting, it was a weapon of marksmanship capable of cutting down any foe within a distance of 100 meters. During the siege of Avaricum in the war against the Gauls, Julius Caesar describes the terrifying precision of the scorpio. In parabolic shooting, the range is greater, with distances up to 400 meters, the firing rate is higher (3 to 4 shots per minute) but the precision is significantly less.
Scorpio were typically used in an artillery battery at the top of a hill or other high ground, the side of which was protected by the main body of the legion. In this case, there are 60 scorpio present which can fire up to 240 bolts per minute at the enemy army. The weight and speed of a bolt was sufficient to pierce enemy shields, and usually also sufficient to wound (or outright kill) the warriors who opposed them.

redpajama_set_name: RedPajamaCommonCrawl


text:
Biografia

Dopo aver servito in adolescenza come sommelier di Carlo V, entrò a far parte della grande chapelle di Filippo I. La sua prima apparizione nei documenti della Corte è del 1501, prima del viaggio di Filippo in Spagna. Reingot seguì il re nel suo viaggio, al seguito della Cappella musicale che era una delle più importanti del tempo in Europa. Essi rimasero in Spagna per parte del 1502 e tornarono in Francia alla fine dell'anno.

Reingot seguì il re anche nel suo secondo viaggio in Spagna, viaggio che si rivelò fatale per il re e per la salute mentale di sua moglie, Giovanna la Pazza. Nel settembre 1506, quando Filippo morì in Spagna a causa di una febbre, molti dei cantori della grande chapelle partirono, la maggior parte con direzione Francia o Paesi Bassi, ma Reingot fu uno dei pochi a rimanere, assieme a Pierre de La Rue. Negli anni seguenti seguirono Giovanna nel bizzarro viaggio attraverso la Castiglia, cantando ogni notte un requiem sulla salma di Filippo, trasportata assieme a loro in una bara, finché Ferdinando II, padre di Giovanna, non fece imprigionare la figlia nella fortezza di Tordesillas ponendo termine al macabro rito e dando sepoltura alla salma del povero Filippo.

Dal 1509, Reingot tornò al nord presso la Cappella di Carlo V, dove rimase fino al 1530. Nessuna sua notizia si ha dopo questa data.

Musica

Anche se la produzione di Reingot potrebbe essere stata più abbondante, solo due sono i pezzi superstiti attribuiti a lui: un mottetto a quattro voci sull'antifona mariana Salve regina ed una chanson a quattro voci, Fors seulement, basata su una melodia di Johannes Ockeghem. La versione di Reingot, presente nella raccolta Canti C pubblicata da Petrucci, utilizza il tema superius di Ockeghem trasposto una ottava sotto nella voce del tenore e le altre tre voci si muovono velocemente attorno ad essa in maniera contrappuntistica.

Note

Bibliografia

Honey Meconi, Pierre de la Rue and Musical Life at the Habsburg-Burgundian Court. Oxford, Oxford University Press. 2003. ISBN 0-19-816554-4

Compositori rinascimentali

redpajama_set_name: RedPajamaWikipedia


text:
Halvor Olsen Folkestad (28 November 1807 – 30 September 1889) was a Bishop in the Church of Norway. He was appointed Norwegian Councillor of State in interim in 1875.

Folkestad was born at Bø in Telemark, Norway. He was the son of Ole Halvorsen Folkestad (1778-1864) and Asberg Augundsdatter (1785-1866). He graduated in 1831 and then worked as a tutor in Gjerpen.  After a year of studies in Christiania (now called Oslo), he received his theological degree in 1836.

In 1841, he was appointed vicar of Mo, Telemark. From 1849 he served for the next 10 years as parish priest in Kviteseid and inspector at Kviteseid Seminary. In 1859, he became as vicar in Fredrikshald (now called Halden). In 1864 he was appointed bishop of the newly created Diocese of Hamar. In 1873, he was appointed by King Oscar II of Sweden to be royal court pastor (). In 1875, he was a member of the interim government during the king's trip abroad.

Folkestad sought and obtained dismissal of the episcopal office in 1887 at age 79. He died at Hamar during 1889 was buried at  Vår Frelsers gravlund in Oslo.

References

1807 births
1889 deaths
People from Telemark
19th-century Lutheran bishops
Government ministers of Norway
Norwegian priest-politicians
19th-century Norwegian Lutheran clergy
Bishops of Hamar
Burials at the Cemetery of Our Saviour


Note: all our observations were done between October 1st and October 4th, 2017.
As part of our review of noon's website, we counted between 150k and 200k displayed products. Whilst this number is under the announced 20 million, it is still an impressive online catalog for a launch, with categories ranging from Electronics to Grocery.
Noon managed to secure key brands across different categories while respecting their merchandising constraints. For example search results page does not display 'Chanel' or 'Dior' lipsticks when a customer searches 'lipstick'. Respecting brand rules, customers can only shop Chanel and Dior beauty products from the brand specific pages.
We noticed that some of the suppliers were renowned local retailers such as Paris Gallery for beauty products, Better Life for appliances or Union Coop for groceries. Alshaya also recently acquired a stake in noon, which altogether reinforces the online platform's intention to being perceived as a quality shopping destination. It will be interesting to see how these partnerships unfold in the future and eventually offer multichannel capabilities to customers.
We observed that there were quite a number of items out of stock. This is likely to be fixed after a few weeks of operations.
Some products were published without images which noon handled gracefully by having a branded placeholder stating "No image available but we sell it".
It seems that product prices are generally aligned to their regional and international competitors. For now the website only has non-personalised promotions in the form of discounts.
In addition to The National and Techradar's price comparisons we ran our own extending the scope of competitors to include multichannel companies.
It is still too early to know whether noon will try to compete on price, promotions or product assortment yet. Nevertheless the new titan is a serious ecommerce contender and will enter the list of retailers to compare prices from. Supporting this affirmation Souq have already responded by dropping product and shipping prices.
The navigation was easy with product categories clearly labeled and key brands featured prominently in the submenus which invokes a sense of confidence in noon as a trusted brand. Some categories were more difficult to find than others; the leading categories were displayed on the horizontal navigation while the remainder were hidden under the "All Categories" dropdown. We found "Audio and Video" under "Home and Kitchen" which we would have expected to see under Electronics and it was not easy to navigate to the whole selection of laptops. However, these small flaws did not alter our general impression of easy navigation across the website.
Filtering was not working for all categories. For example the facets proposed for Lancôme brand subcategory were irrelevant. While this is to be expected when launching a webstore with such a big assortment, it is very important to get this right quickly since this is one of the main ways for customers to find the product they are looking for in a large product catalogue.
The search engine did a very good job ("water" returns water bottles and "water dispenser" returned, well, water dispensers) and had a powerful autosuggestion feature. This is not an understatement. A good search engine is one of the crucial elements to the success of an ecommerce website.
The cross-selling features ("you might also like" or "customers who bought this item also bought") were not relevant though and felt misplaced in the basket just before checkout.
The checkout flow was seamless with only 3 steps – shipping address, payment details and order confirmation. It was also pretty fast, for a new user it took only 1 minute to fill in all required data.
Two payment options were given – by card (Visa, Mastercard, American Express) or cash. Paypal was not proposed even though it is widely used by other online stores in the region. There was a message stating that noon don't store any payment card information, which can be reassuring to some shoppers, as many in the region are still wary when it comes to online payment. However, during placement of several orders we saw that the card was saved anyway even though there was no option to save the card during the checkout.
The delivery charge was 10 AED for orders below 100 AED and there was no minimum order. This is highly attractive compared to the competition. We couldn't find information about cash on delivery charges and change handling at delivery.
The standard shipping time is next day for orders fulfilled by noon and up to 4 days for orders fulfilled by third-party sellers. Customers don't have the option to select date and time of the delivery. This is a must-have when shopping groceries online.
In a nutshell, we found all the basics were in place, on par and even beyond regional standards. A one-click purchase button and more payment and delivery options would make the marketplace even better.
On the downside we noticed several important data validation and session management loopholes during checkout, especially for guest checkout, which we hope will be fixed soon.
Noon is noticeably the first Arabic-first ecommerce website. The User Interface was perfectly written and the typography worked well. The website is de facto setting a new design standard in the region.
The responsive behaviour of the website worked well throughout and the design was well adapted for mobile. We also tested noon's mobile apps which were lightweight and as intuitive to use as the responsive website with images loading quickly. Surprisingly, we weren't able to find them on both Android and IOS app stores by searching for 'noon' (it did work for 'noon ecommerce').
With their editorial-like homepage and clean graphics noon feels more like a department store than a marketplace, which fits with their initial statement of being a premium shopping destination.
The product list page had an efficient and well spaced grid layout with big images. We found the prices difficult to scan as they are visually blended with the product title text. The promotions were hard to spot and inconsistently displayed. Sometimes the discount sticker appeared and sometimes not. In our opinion the display can be further improved for categories such as grocery.
The product detail page layout was very well designed above the fold, with key information visually hierarchised. We found the cross-sell carousel oversized, which caused annoyance when scrolling to view the product descriptions. This annoyance was exacerbated by the fact the product descriptions were lacking in information. Lastly, the customer reviews integration was questionable as it was a concatenation of many other website's reviews. This raises the question of relevance for the regional customer base but it is good to have some authentic reviews on there.
Upon adding an item to the basket users are automatically taken to the cart summary page, which in our opinion adds an unnecessary step and deters users who want to continue shop on the website. This will become increasingly frustrating for grocery shoppers in particular.
We ordered grocery supplies for our office as a test run and unfortunately only 5 items out of 14 were delivered on time. All the remaining items were delivered the next day, without additional charges.
The emails we received were nicely designed, which proves noon pay attention to the customer experience beyond the website. Incidentally, we did not receive any account creation confirmation email after we registered. The first email we received was the order confirmation email.
Customer support chat is provided which is very good and helpful but we will need to review its efficiency after a few days of operations as on the first day we waited for more than 10 minutes without any response.
The packaging was of very high quality, and was delivered by an employee dressed on-brand as well.
In a nutshell, the quality of the user experience through the entire customer journey was above regional standards. Branding was perfectly executed from the homepage through to packaging, getting them on-par with successful omnichannel department stores.
There were pitfalls and areas of improvement regarding customer journey efficiency, for instance when it comes to account confirmation email and stock control. We believe that these can rapidly be corrected since the basics are solid.
We were impressed by the loading performance on desktop. Product pages load very fast (less than 1s) and checkout is seamless. However, we found the website on mobile and the apps were slower than average, slightly dampening our first impression.
We also observed cross-browser issues, for example Firefox on mobile returned a blank page and desktop Safari loaded only the Help chat on the bottom right hand corner, without any data.
Lastly from an SEO perspective we noted that the product pages were not indexed in Google and they did not have the required metadata so far, although long tail is one of the key ingredients of a successful marketplace.
Noon's launch was worth the wait as the overall front-end execution quality, excellent page load performance, search features and design execution largely met our expectations. The product catalogue, although not as big as announced, is impressive especially considering the product data is also in Arabic.
There were a certain number of important defects to be fixed urgently given the exposure noon has at the moment mostly concerning product stock, handling of customer data and user sessions.
We hope noon will swiftly correct the issues we encountered and extend their product assortment and content in order to catch up with their direct competitors. In particular considering Amazon are anticipated to unveil aggressive development plans in the region.
This said, noon already showed they will play a key role in the regional landscape, and may well become to ecommerce what Dubai Mall is to retail.


JB Architectural Ironmongery in Newhaven, is the UK distributor and suppliers of Wilka and SSF locks for wooden doors. In the Wilka and SSF range there is a solution to fulfill your requirements.
For further information or to place an order for Wilka or SSF wooden door locks, please contact us today and speak to a member of our friendly, experienced team.


A grieving family has appealed for help to find out how a grandfather was exposed to fatal quantities of asbestos.
Gerald Taylor died aged 76 in December, last year, after a long battle with lung disease linked to contact with large amounts of the deadly substance.
The father-of-two, from Barry, had described working in a "haze of asbestos all the time" while an electrical maintenance contractor in Aberthaw B Power Station near Cardiff between 1967 and 1979.
His family has instructed law firm Slater and Gordon, which specialises in industrial disease cases, to launch legal action against his former employers Alstom (Formerly GEC Power Engineering Turbine Generators).
His daughter Cammelia Hooper, 45, called for anyone who worked with her father, or in the same power station around the same period and saw asbestos, to come forward with information about the working conditions.
She said: "My dad's condition really deteriorated towards the end. It made him very weak.
"My mum remembers him coming home from the power station covered in dust – it was a dirty and unpleasant environment for him.
In a statement made before his death, Mr Taylor said: "On virtually every day I worked with laggers who were mixing loose asbestos with water all around me. They poured the loose asbestos from bags into drums filled with water which created an enormous amount of asbestos fibres being released into the air.
The family's lawyer, Alison Kerr of Slater and Gordon, said: "Mr Taylor's life was cut short because of his contact with asbestos.
"Despite the risks of asbestos having been known for decades, he was still sent to work in dangerous conditions. Now his family want to make those who exposed him to those conditions accountable.


Based on a couple of posts over at the Locost USA forum, we decided not to trust to luck that the donor engine would start on the first try once it was bolted into the Locost. Better to get it running in the M.G., we thought. So we went ahead and pulled the head to check the engine internals, which is a really simple task on an M.G. Back in the day we could have the head off an MGB in an hour. This time it took two, but there's a lot more junk bolted to the engine in the post-emissions era. And we're a little rusty.
The good news is, almost all the nuts and bolts came off really easily. Although we still haven't managed to separate the thermostat housing from the head. There's some kind of bluish glue-like substance oozing out from under the flange, so that piece might need a little extra persuasion. The spark plugs look a tad black, which either means the engine was running slightly rich, or else tan electrodes turn black after many years of neglect. The valves have a little bit of carbon baked on, not bad though. No evidence of cracks in the head or any burnt valves.
Inside the engine, the cylinder walls were mirror-smooth, but kind of dry, especially toward the bottom, which was expected. We bumped the engine by pushing the car with the transmission in gear, and the pistons moved easily, great news on two fronts because it proves conclusively that the drivetrain works. We ran some oil around the cylinder walls and left that to soak into the rings. A quick peek under the distributor cap revealed an intact rotor and no serious crud, so we're confident once we put everything together the car will start.
The S.U. carburetors weren't the old HS4s that we used to work on, but being a later design they should work better, or at least that's what we'd like to believe. They're similar to HS4s, but with more tubes running out of them, most likely for some kind of emissions purpose, and built-in float bowls. They looked okay, but the chokes on both carbs were glued shut. We're guessing the culprit was varnish, which we think is automotive speak for dried-up petrol. In any case, copious amounts of WD-40 sprayed in and about the choke mechanisms eventually freed them up.
There are about a million vacuum lines running around the engine bay, or if not a million then at least half a dozen, and since the car needs exactly one, for the timing advance (brakes are unboosted), we have to believe the rest are there in a futile attempt to clean up the exhaust. Of course we'll have to remember to put them all back in place exactly how we found them. Because while pre-1975 cars aren't tested for emissions in California, they are still required to have all of their original emissions equipment installed and operating, and it could be illegal for us to suggest we might do otherwise.
We're not going to replace too much on the engine at this point, at least until we know for sure that something isn't working. We did order a new thermostat, which we'll install if we can ever pry the housing loose. Replacing coolant hoses would be a waste, since the stock hoses won't work on the Locost. The carburetor heat shield had cracked, been tack welded, and cracked again, so we repaired it with a strip of 18 gauge steel and a couple of pop rivets, then painted it with silver Engine Enamel. And everything will be getting new gaskets. Except maybe the thermostat housing.


The dramatic highs and lows of David's life make for good story telling. Even those of us raised outside of the church were told of his underdog battle with Goliath. In The Heart of An Executive, however, Richard Phillips takes a fresh look at these familiar biblical accounts, from the perspective of what we can learn about leadership from the life of David.
The author emphasizes David's leadership style by first recounting the story of the people's demand to be like the nations surrounding them, with a king to rule over them. God punished their lack of faith by giving them what they wanted, in King Saul. Where David introduced us to the concept of the leader as a self-sacrificing shepherd, Saul exhibited a self-serving and arrogant leadership style. Where David was guided by a compelling vision for his people, Saul thought only of the moment.
Even more convicting, the author reminds us that "there is a Saul within each of our breasts, a Saul even within the anti-Saul David," and so the low moments in David's life, where he is motivated by impulse and far from being a man of prayer, are also used to teach valuable lessons about what godly leadership doesn't look like.
At times, the parallels between the dramatic events of David's life and the relatively mundane drama of the boardroom seem a little stretched and awkward. However, Richard Phillips is an engaging story-teller who manages to avoid the shallowness of many other Old Testament biographies.
Who should read it? This isn't a book written for academics, but is an accessible quick read for anyone who in the church, in the workplace, or in the home finds themselves in a position of responsibility.


text:
Statistiche

Presenze e reti nei club
Statistiche aggiornate al 18 febbraio 2023.

Palmarès

Club

Competizioni nazionali

Rangers: 2020-2021

Rangers: 2021-2022

Individuale
Capocannoniere dell'English Football League Trophy: 1
2015-2016 (4 reti, alla pari con Lee Gregory e Jory Hiwula)

Note

Collegamenti esterni

Calciatori della Nazionale giamaicana


We collect certain information that you voluntarily provide when you create an account with us. This information may include personally identifiable information such as your name and email address as well as a password that you create. You may access and make changes to your stored account information at any time by logging into your account and clicking on the "My Account" link. When you use our Web Site, Content, purchase one of our products or services, we ask for additional personally identifiable information such as your credit card information and billing address solely for the purpose of processing your payment and fulfilling your order. We may use certain standard web measurement and tracking technologies, such as "cookies," web server logs, or other statistics programs to collect information about you, your online behavior, and/or your computer or other device from which you access our web site. This information may include your preferences and settings, IP address, browser type, web pages visited, date and time of those visits, content viewed, the website you arrived from, and other clickstream data. If you do not want this type of information to be collected, your computer or other device may allow you to block the use of these technologies. (Doing so make af-fect the functionality of our site.) In addition, we may utilize use web beacons (al-so known as "action tags" or "one pixel .gif files"), provided by our advertising serving partner, to measure the effectiveness of, and otherwise manage, our online advertising. These web beacons enable our advertising server to recog-nize you when you visit our Web Site and to determine which banner ads bring users to our Web Site. We do not use spyware, adware or any other similarly in-trusive software.
If you provide your consent, we may share with third parties information about what you watch and other activity, such as viewing history and ratings. In addi-tion, we also may use and share your viewing activity to improve our service or the experience for other users in a way that does not personally identify you to such users. You can set your sharing preferences in your Account.
We implement generally accepted industry standards to protect the personal in-formation submitted to us, both during transmission and once we receive it. If you have any questions about the security of our Web Site, please contact our Priva-cy Policy Coordinator (see below). We cannot guarantee that your personal in-formation may not be accessed, disclosed, altered, or destroyed as a result of a breach of our commercially reasonable efforts or as a result of any other event beyond our reasonable control. Accordingly, we cannot and do not guarantee that your personal information is completely secure and safe from such risks. FOR THE AVOIDANCE OF DOUBT, WE EXPRESSLY DISCLAIM ANY REP-RESENTATION OR WARRANTY, WHETHER EXPRESS OR IMPLIED, WITH RESPECT TO ENSURING, GUARANTEEING OR OTHERWISE OFFERING ANY DEFINITIVE PROMISE OF SECURITY IN CONNECTION WITH YOUR PERSONAL INFORMATION OR USAGE INFORMATION.
If you are located outside the United States and choose to provide information to us, we may transfer your information to the United States (or any other country where we operate), where the privacy laws may not be as protective as in your country or jurisdiction. By using our Web Site, you consent to the collection, transfer, use, storage, and disclosure of your information as described in this Pri-vacy Policy.
Our Web Site, resources, and tools are intended for users who are at least 18 years of age. We do not knowingly allow anyone under 18 years of age to regis-ter with, or to provide any personal information to, us.
Please also visit our Terms of Service (https://bodyconceptions.intelivideo.com/page/terms-of-service/), which govern the use, liability, and limitations of our Web Site and services.


text:
Q: Autowiring a DAO into a domain object I am coding a ribbon/achievements system for a website and I have to write some logic for each ribbon in my system. For example, you could earn a ribbon if you're in the first 2,000 people registering to the website or after 1,000 post in the forum. The idea is very similar to stackoverflow's badges, really.
So, every ribbon is obviously in the database but they also need a bit of logic to determine when a user has earned the ribbon.
In the way I coded it, Ribbon is a simple abstract class:
@Entity
@Table(name = "ribbon")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "ribbon_type")
public abstract class Ribbon
{
    @Id
    @Column(name = "id", nullable = false, length = 8)
    private int id;

    @Column(name = "title", nullable = false, length = 64)
    private String title;

    public Ribbon()
    {
    }

    public abstract boolean isEarned(User user);

    // ... getters/setters...
}

You can see I define the inheritance strategy as SINGLE_TABLE (since I have to code like 50 ribbons and I don't need additional columns for any of them).
Now, a specific ribbon will be implemented like this, for example:
@Entity
public class First2000UsersRibbon extends Ribbon
{
    @Autowired
    @Transient
    private UserHasRibbonDao userHasRibbonDao;

    public First2000UsersRibbon()
    {
        super.setId(1);
        super.setTitle("Between the first 2,000 users who registered to the website");
    }

    @Override
    public boolean isEarned(User user)
    {
        if(!userHasRibbonDao.userHasRibbon(user, this))
        {
            // TODO
            // All the logic to determine whether the user earned the ribbon
            // i.e. check whether the user is between the first 2000 users who registered to the website
            // Other autowired DAOs are needed
        }
        else
        {
            return true;
        }

        return false;
    }
}

The problem is that userHasRibbonDao is null inside the isEarned() method, so a NullPointerException is thrown.
I thought that having DAOs autowired into domain objects was wrong, but in this topic they told me that it's the correct approach (Domain-Driven Design).
I shared a non-working very simple example on GitHub: https://github.com/MintTwist/TestApp (remember to change the connection details in /WEB-INF/properties/jdbc.properties and to import the test_app.sql script)
Any help very appreciated.
Thank you!
Update - Reading the first answers, it seems like my approach is completely wrong. How would you ideally structure the code given that there may be 50-70 different ribbons? Thanks

A: I'm not saying that I agree with injecting DAOs into domain instances....but
You can wire your DAO into you domain object. But you'll have to declare your domain object in your spring application-context and obtain new instances from Spring NOT using new. Make sure that you use the prototype scope! You don't want to be getting the same singleton instance everytime!
Really this logic that you want to implement belongs in a service which is injected with the DAOs that it requires.
Perhaps you could have a service like:
@Service
public class RibbonServiceImpl implements RibbonService

  @Autowired
  private RibbonDAO ribbonDAO;

  public boolean isEarned(Ribbon ribbon, User user) {
   if(!userHasRibbonDao.userHasRibbon(user, this))
        {
            // TODO
            // All the logic to determine whether the user earned the ribbon
            // i.e. check whether the user is between the first 2000 users who registered to the website
            // Other autowired DAOs are needed
        }
        else
        {
            return true;
        }

        return false;
  }

A: Mark it as @Configurable - @Configurable annotion will ensure that even if the beans are created outside of Spring, the dependencies are injected
You also need to add <context:spring-configured/> in your context.

A: One answer is missing, and it's not pretty, but it works. Instead of wiring the Dao, you can look it up from the WebApplicationContext:
RibbonDao dao = ContextLoader.getCurrentWebApplicationContext.getBean(RibbonDao.class);

This is the opposite of everything dependency injection stands for (I like to call this pattern "Inversion of Inversion of Control" :-)), but then: so is injecting services into Domain Objects.

A: You can also try using the @Component annotation declaring along with the @Entity annotation on your First2000UsersRibbon class. And make sure that the package having this class is there in <context:component-scan base-package="" />. And along with this you need to make sure that the object of this class is not created using new operator.
Hope this helps you. Cheers.

A: As Alex already mentioned is not a good practice to have your application entities as beans within your context. There are a lot of cumbersome things that can happen and it doesn't look like a good design.
The code will look something like this:
public abstract class Ribbon{

    public abstract boolean checkUser(User user);
}

public class NewUserRibbon extends Ribbon{

    @Override
    public boolean checkUser(User user){
        // your logic here
    }
}

In your Service you can have a cache collection of all the ribbons in the system (unless they are dynamic), I would suggest even to classify the ribbons by event triggers (new users, answers, votes, etc..), so you can check in your services just for the appropriate ribbons (instead of all of them), by iterating over the applicable ribbon list with the current user.

A: From what I can see the design of your hibernate classes, and the persistence of earned ribbons, is fine. I think the problem is about when and how you decide whether a User has earned a new ribbon.
Lets say a new request comes in from a logged in user. The User object is created and populated by Hibernate, and we now know all the Ribbons already earned by that User, in the userHasRibbonSet. We probably need a method like this in User:
public boolean hasEarnedRibbon(Ribbon ribbon) {
    for (UserHasRibbon userHasRibbon : userHasRibbonSet) {
        if (userHasRibbon.getRibbon().equals(ribbon) {
            return true;
        }
    }
    return false;
}

(this could probably be optimised by caching the ribbons themselves in a Set and doing a constant-time lookup, but that isn't key here)
The request is processed, the User object is updated to reflect what has happened. Then, on the way out, you check what Ribbons the User has now earned, something like this:
public class RibbonAwardingInterceptor extends HandlerInterceptorAdapter {

    @Resource
    private SessionFactory sessionFactory;
    @Resource // assuming it's a request-scoped bean; you can inject it one way or another
    private User user;

    public void postHandle(HttpServletRequest request, HttpServletResponse response,
       Object handler, ModelAndView modelAndView) throws Exception {

        List<Ribbon> allRibbons = sessionFactory.getCurrentSession().createQuery("from Ribbon").list();

        for (Ribbon ribbon : allRibbons()  {
            if (!user.hasEarnedRibbon(ribbon)) {
                // The user has not previously earned this ribbon - lets see if they have now
                if (ribbon.isEarned(user)) {
                    user.getUserHasRibbonSet().add(new UserHasRibbon(user, ribbon));
                }
            }
        }
    }
}

If you want to use this exact pattern, make sure this interceptor goes after any interceptors that update the User in a way relevant to ribbons, but before the interceptor that closes the transaction (assuming you are using the transaction-per-request model). Then flushing the Hibernate Session will update the UserHasRibbon table automatically, so there is no real need for a dedicated DAO.
This is a simplistic approach and can obviously be refined. A clear improvement would be to be more selective with the Ribbons you are checking. Maybe each Controller method could finish by checking if any relevant Ribbons are now applicable - the Controller should know which Ribbons may be awarded after it's action.
Hope that helps, please let me know if I have completely missed the point and I'll try again.

A: I think you need to tweak your design. The first question I had was "how come your Ribbon class has the ability to check which user has it?" It's like saying the kitchen table should have a method called boolean doesThisKitchenHaveMe(Kitchen k).
It seems more logical to me that you need a 3rd locator service that maps a ribbon to an user

A: Why use DAO in the DomainObject? I suggest to decouple DAO and DomainObject, because (IMHO) the method isEarned(User user) is not relevant for First2000UsersRibbon.
class UserHasRibbonDao {
    public boolean isEarned(User user){
        if(!userHasRibbonDao.userHasRibbon(user, this)) {
        // TODO
        // All the logic to determine whether the user earned the ribbon
        // i.e. check whether the user is between the first 2000 users who registered to the website
        // Other autowired DAOs are needed
        } else {
           return true;
        }

        return false;}
}

redpajama_set_name: RedPajamaStackExchange


text:
Home News BREAKING !!! Flydubai Boeing Aircraft crash in Southern Russia Rostov, All 62 on board including crew members killed
BREAKING !!! Flydubai Boeing Aircraft crash in Southern Russia Rostov, All 62 on board including crew members killed
at 1:58 am News,
A Flydubai Boeing 737-800, registration A6-FDN performing flight FZ-981 from Dubai (United Arab Emirates) to Rostov on Don (Russia) with 55 passengers and 7 crew, had aborted the approach to Rostov's runway 22 at 01:41L (22:41Z) due to weather and entered a hold initially at 8000 feet, after 30 minutes at 8000 feet the aircraft climbed to FL150. After about 2 hours of holding the aircraft commenced another approach to Rostov's runway 22, winds from 240 degrees at 27 knots (14 m/s) gusting 42 knots (22 m/s), the crew announced a go around, the aircraft however impacted ground just off the runway at about 03:43L (00:43Z), broke up and burst into flames. There are no survivors.
The aircraft carried fuel for trip, contingency, alternate, final fuel reserve (30 minutes) and additional holding for about 2:30 hours, total fuel for an endurance of about 8.5 hours. The aircraft had been airborne until time of impact for 06:02 hours.
Russia's Ministry of Emergencies reported that more than 700 people and more than 100 vehicles have been deployed to the crash scene for search and recovery operations following the aircraft crash. The aircraft struck a wing onto the runway on touch down and began to disintegrate.
Russia's MAK (Interstate Aviation Committee, Accident Investigation Board) reported the aircraft broke up and burst into flames upon touching ground, debris is spread over a large area (several kilometers). An investigation has been opened. Both black boxes were recovered in good condition, work to read out the blackboxes has already started.
https://www.youtube.com/watch?v=v9taAaAU0Tg
The NTSB announced on Mar 19th 2016, that they are going to assist the MAK in the investigation.
On Mar 19th 2016 Boeing announced to assist the MAK's investigation as technical advisors.
The airline confirmed the aircraft crashed on landing in Rostov, there were no survivors. In a press conference the chairman added, that the captain had 5,900 hours of flying experience, the first officer 5,700 hours. Flydubai have dispatched an emergency response team to Rostov to assist families and to assist the investigation.
Radar data suggest the aircraft on final approach was to the left of the localizer and just to the left of the left runway edge and corrected to the right while over the runway bringing the aircraft just within the runway edges moments before ground contact.
https://www.youtube.com/watch?v=Ue3T4-x_2dE


text:
Chiadzwa drifting in wrong direction
By Nehanda Radio	 On Jun 28, 2018 13,626
Illegal diamond panning in Marange
Despite the general consensus that the country did not benefit from the previous mining regime that existed in the Chiadzwa diamond fields before the formation of the Zimbabwe Consolidated Diamond Company (ZCDC), events on the ground suggest that it may not be long before we revert to the old order, which prejudiced the fiscus of billions of dollars in lost revenue.
Marange diamond panners
This follows the dismissal last week of an appeal by ZCDC in the Supreme Court, barring the government-owned company from entering diamond concessions that were allocated to Mbada Diamonds years back.
Mbada was part of a select group of companies that were pushed out of the controversial diamond fields in 2016 after former president Robert Mugabe's regime took the decision to cancel their licences.
The cancellation gave rise to a bruising court battle between ZCDC, which now has the sole mandate to extract the gems on behalf of government, and Grandwell Holdings — a major shareholder in Mbada Diamonds.
State owned ZCDC management fails to account for US$300…
Jul 19, 2021 27,565
Rare, precious diamonds discovered by Russian firm in…
Watchdog says more firms mining secretly in game parks…
Sep 19, 2020 17,472
Manica Diamond players go without pay
Jun 23, 2020 13,669
Several court orders were made in favour of Grandwell, with ZCDC appealing against each judgment made in the lower courts.
Our reading of the Supreme Court ruling is that the road has now come to an end and it is just a matter of time before Mbada Diamonds bounces back.
What we are seeing are moves taking the country back to the previous, chaotic order in the name of respecting the rule of law even though it is quite clear that the current arrangement is in the country's best interest.
Instead of going back to the dark days when the fiscus suffered massive prejudice, we feel that the parties concerned should find ways of safeguarding ZCDC's interests, while addressing compensatory issues for those that sought redress in the courts.
Our fear is that the rule of law could be abused to sanitise ulterior motives that benefit only a few at the expense of the majority, including communities in Marange that were now working well with ZCDC.
Government now needs to pronounce itself clearly in the wake of last week's Supreme Court ruling, guarding against the immorality whereby a few individuals, using their connections in the establishment, were holding the whole nation at ransom.
Never again should we allow the police, army and the spy agency getting themselves involved in diamond mining, because that is not their brief.
Experiences gleaned from other countries show that the current model must be maintained because it offers better accountability and easy monitoring of diamond revenues. Daily News
ChiadzwaChiadzwa diamond fieldsGrandwell HoldingsMbada DiamondsZimbabwe Consolidated Diamond CompanyZimbabwe diamonds
Mnangagwa fails to show up
Mai Titi BLASTED over grenade skit
State owned ZCDC management fails to account for US$300 million
Rare, precious diamonds discovered by Russian firm in Matabeleland South
Watchdog says more firms mining secretly in game parks despite ban
Zimbabwe losing billions in Chiadzwa as top army chefs continue looting
Chiadzwa Part 2: A story no one would ever tell… what US$15 billion could have…