| TOC |
|
OAuth Core 1.0 defines a protocol for delegating user access to Consumer applications without sharing the user's private credentials. The protocol specifies a set of configuration values that enable Consumers to find and communicate with the Service Provider. However, OAuth Core leaves the process of communicating that information undefined.
The discovery protocol provides a way to for Consumers to receive the required configuration data from the Service Provider in a machine-readable format. It creates an extendable framework for communicating current and future services and extensions.
The protocol has been designed to keep the workflow as simple as possible, use existing discovery practices, and maintain strong flexibility allowing Service Providers to structure their configuration as needed.
1.
Notation and Conventions
2.
Definitions
3.
Scope and Limitations
4.
Realms
5.
Discovery Workflow
5.1.
Identify the Resource Realm
5.1.1.
Service Providers
5.1.2.
Consumers
5.2.
Retrieve the Discovery Definition Document
5.3.
Parse the Discovery Definition Document
5.3.1.
Document Structure
5.3.2.
Realm Definition Element
5.3.3.
Service Types
5.3.4.
Service Element
5.3.5.
oauth:CustomParameters Element
5.3.6.
oauth:RequestParameterMethods Element
5.3.7.
oauth:RequestSignature Element
5.3.8.
Append Attribute
5.3.9.
Service Extensions
5.3.10.
Parsing Process
5.4.
Establish Consumer Identity
5.4.1.
Static Allocation
5.4.2.
Dynamic Allocation
5.4.3.
Manual Allocation
5.4.4.
Complex Consumer Realm
5.5.
Establish User Access
Appendix A.
Appendix A - Examples
Appendix A.1.
Simple Discovery Definition Document
6.
References
§
Author's Address
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .). Domain name examples use [RFC2606] (Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” .) and OAuth extension examples use the URI prefix http://oauth.net/example/.
Unless otherwise noted, this specification is written as a direct continuation of [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .), inheriting the definitions and guidelines set by it.
| TOC |
- OAuth Discovery:
- A general name for the workflow described in this specification.
- Consumer Identity:
- The Consumer Key, Consumer Secret, and any other information used to establish an identity for the Consumer such as public key.
- Realm:
- An absolute HTTP(S) URL used to group Protected Resources together by associating them to the URL. Realms allow sharing information across multiple Protected Resources.
- Resource Realm:
- Realm for sharing OAuth configuration across multiple Protected Resources.
- User Realm:
- Realm for sharing an Access Token across multiple Protected Resources.
- Consumer Realm:
- Realm for sharing a Consumer Identity across multiple Protected Resources.
- Realm Definition:
- An XRD element containing the Service Provider OAuth configuration, in a machine-readable format.
- Discovery Definition Document:
- An XRDS document which binds together Realm Definitions and other services, in a machine-readable format.
- OAuth Endpoints:
- The group of four request endpoints defined by [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) (Request Token, User authorization, Access Token, and Protected Resource).
| TOC |
While a fully automated discovery process of authentication, authorization, and services is a highly desired objective, OAuth Discovery is inheritably limited. In many cases, Consumer Key allocation requires human interaction. This is done for legal, compliance, or other reasons, which hinder automated discovery without prior manual registration.
OAuth Discovery does not address the methods in which Protected Resources are accessed. Without clear standards of the Protected Resources space, any discovery protocol will eventually require some form of external handling of the Protected Resources. However, combines with other specifications, the entire process can be fully automated from authentication, through authorization, to services.
OAuth Discovery is designed to accommodate two scenarios:
Service Providers MUST support Automated Initiation, and MAY support Manual Initiation by providing the information needed in documentation or other means.
| TOC |
OAuth Discovery uses Realms to associate Protected Resources to a common configuration used for OAuth authentication. A Realm MUST be a valid endpoint URL pointing to an accessible resource using HTTP requests. Service Providers MAY put access restrictions on the Realm URL. In order for the Consumer to perform the OAuth Discovery workflow, the Consumer requests the resource at the Realm URL.
Each Protected Resource MUST be associated with a Resource Realm, which in turn identifies the resource's User Realm and a Consumer Realm. In order to enable complex configuration of Realms without complicating the workflow, a Protected Resource may omit an explicit User Realm or Consumer Realm association, allowing them to implicitly default to the value of the Resource Realm.
The User Realm and Consumer Realm inform the Consumer when established credentials MAY be reused between Protected Resources. Realms are valid values of the realm parameter as defined in [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” .) section 1.2, but are more restrictive in their requirements and syntax.
| TOC |
The OAuth Discovery workflow centers around the retrieval and parsing of the Discovery Definition Document which is the machine-readable format of the [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) configuration. While both the Service Provider and Consumer play a role in the workflow, it is focused on actions performed by the Consumer. The workflow includes the following steps:
Once all steps have been performed, the Consumer has the required OAuth credentials to access the Protected Resource following the [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) section 7 workflow.
| TOC |
Service Providers are likely to offer multiple Protected Resources, and MAY choose to partition access to them. Partitioning is done by associating Protected Resources to a Resource Realm, a common unique URL. Each Resource Realm has its own Realm Definition contained within a Discovery Definition Document.
Service Providers identify the Resource Realm of each Protected Resource, which is used by the Consumers locate the Discovery Definition Document for that Realm.
| TOC |
Service Providers MUST identify the Resource Realm of each Protected Resource when denying Consumer access due to lack of OAuth credentials. Service Providers MAY document Realm information via other means to enable Manual Initiation.
The Resource Realm is provided by at least one of the following methods in decreasing preference:
In case the Service Provider supports the OAuth HTTP Authorization Scheme, but does not support OAuth Discovery, the Consumer will fail to locate a valid Discovery Definition Document by requesting the resource at the Resource Realm URL.
| TOC |
When attempting to access a Protected Resource using OAuth, the Consumer MUST first identify the Resource Realm. This allows the Consumer to check if it has already performed OAuth Discovery on that Realm and can reused that configuration. Consumers MUST NOT use configuration obtained for one Resource Realm with another.
To obtain the Resource Realm, if it has not been provided as part of a Manual Initiation process, the Consumer attempts to access the Protected Resource by making a request to the Protected Resource endpoint without any OAuth credentials. The request will fail with the Service Provider indicating the Resource Realm in its response.
To identify the Realm, the Consumer MUST analyze the Service Provider response by searching in order the list of supported Realm containers (Service Providers) for a Realm value, and MUST stop as soon as the first Resource Realm is found.
| TOC |
The Consumer retrieves the Discovery Definition Document from the Realm using the Yadis protocol as defined in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) section 6. If the Yadis protocol is successful, the Consumer obtains the Discovery Definition Document. If the Yadis protocol fails, it SHALL be assumed that the Service Provider does not support OAuth Discovery.
| TOC |
The Discovery Definition Document is an XRDS-formatted document providing a machine-readable representation of the OAuth configuration needed to allow Consumers access using [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .). The XRDS format provides a simple and extendable framework and is defined in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) section 4.
OAuth Discovery uses a subset of the elements defined in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .). Service Providers MAY use XRDS tags and attributes not listed in this specification but such elements MUST NOT change the meaning or behavior of the Discovery Definition Document from an OAuth Discovery standpoint. Consumers MAY ignore XRDS tags and attributes not listed in this specification. All elements not beginning with "oauth:" are defined in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) section 4. If a conflict exists between this specification and [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .), the definitions in this specification are to be used.
Unless otherwise noted, all tags, attributes, values, and XML namespaces are case sensitive.
| TOC |
The Discovery Definition Document is a valid XRDS document. It contains a single XRDS root element. For example:
<XRDS xmlns="xri://$xrds">
The XRDS element MUST include at least one Realm Definition and MAY include any number of other XRD elements which are ignored in OAuth Discovery. Realm Definitions MUST include the xmlns:oauth attribute with a value of http://oauth.net/discovery/1.0. For example:
<XRD xmlns:oauth="http://oauth.net/discovery/1.0" xmlns="xri://$XRD*($v*2.0)">
Each Realm Definition describes a Resource Realm, a User Realm, a Consumer Realm, or any combination, and contains Service elements describing OAuth endpoints or other services. The document MUST NOT include more than one Realm Definition per Realm, and MAY include one and only one Realm Definition unbound to a specific Realm, which serves as a catch-all element. The order in which XRD elements appear in the document MUST NOT affect its meaning.
| TOC |
The Realm Definition is an XRD element which contains the xmlns:oauth attribute and the following elements:
- <Query>
- 0 or 1 per Realm Definition with type xs:anyURI. Value identifies which Realm the definition covers, MUST contain a valid Realm, and MUST NOT be empty. A Discovery Definition Document MUST NOT contain more than one Realm Definition with a missing Query element.
- <Expires>
- 0 or 1 per Realm Definition with type xs:dateTime. Consumers MUST NOT use the Realm Definition after the given expiration. If a newly retrieved document contains expired Realm Definitions, they MUST be ignore. If a cached document contains expired Realm Definitions, the Consumer MUST discard the document and obtain a newer copy. If the HTTP transport caching semantics specify a different expiration time, the Consumer MUST use the earlier of the two.
- <Service>
- 0 or more per Realm Definition as defined in Section 5.3.4 (Service Element).
- <oauth:Realm>
- 0 or more per Realm Definition with type xs:anyURI. Value MUST contain a valid Realm and MUST NOT be empty. Element MUST contain a type attribute set to either user or consumer based on the Realm type. The element supports an OPTIONAL priority attribute as defined in [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02,” .) section 4.3.3.
- <oauth:RequestParameterMethods>
- 0 or 1 per Realm Definition as defined in Section 5.3.6 (oauth:RequestParameterMethods Element).
- <oauth:RequestSignature>
- 0 or 1 per Realm Definition as defined in Section 5.3.7 (oauth:RequestSignature Element).
- <oauth:Reference>
- 0 or 1 per Realm Definition with type xs:anyURI. Value MUST be a valid discoverable Realm. The element is used to reference another Realm while retaining the Protected Resource Realm association. When a oauth:Reference element is used, is MUST be the only element contained in the Realm Definition with the exception of Expires and Query. The referenced Realm MUST NOT contain another oauth:Reference element.
| TOC |
Realm Definitions use Service elements to document the endpoints and services associated with the OAuth workflow. The Service element contains a child element Type which is used to indicate the type of service described.
To identify the OAuth Endpoints, each is given a unique URI, listed with their [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) section reference:
- Request Token:
- http://oauth.net/core/1.0/endpoint/request - section 6.1.1.
- User Authorization:
- http://oauth.net/core/1.0/endpoint/authorize - section 6.2.1.
- Access Token:
- http://oauth.net/core/1.0/endpoint/access - section 6.3.1.
- Protected Resource:
- http://oauth.net/core/1.0/endpoint/resource - section 7.
Service elements MAY contain multiple Type elements and as follows:
| TOC |
The Service element contains the OPTIONAL priority attribute and the following elements:
- <Type>
- 1 or more per Service element with type xs:anyURI as defined in Section 5.3.3 (Service Types). The Type element supports an OPTIONAL oauth:required attribute with type xs:boolean and default value false if omitted. The oauth:required attribute MUST NOT be used with service types defined in this specification and is provided for discovery extensions (Service Extensions).
- <URI>
- 0 or 1 per Service element with type xs:anyURI. The value is the URL the Consumer uses in the [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) protocol. Service elements for the OAuth Endpoints MUST include a URI element expect for http://oauth.net/core/1.0/endpoint/resource which MUST NOT.
- <oauth:HttpMethod>
- 0 or 1 per Service element with type xs:string. oauth:HttpMethod elements MUST be present and have a non-empty value when, and only when, the URI element is non-empty, except for http://oauth.net/core/1.0/endpoint/authorize which MUST NOT have an oauth:HttpMethod element. The value is the HTTP method used to request the URL provided in the URI element. The oauth:HttpMethod element supports an OPTIONAL source attribute with type xs:anyURI which indicates the source of the HTTP method definition. If omitted, the source attribute defaults to http://www.ietf.org/rfc/rfc2616 which enables using the methods defined in [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .) as values for the oauth:HttpMethod element: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, and CONNECT.
- <oauth:CustomParameters>
- 0 or 1 per Service element as defined in Section 5.3.5 (oauth:CustomParameters Element). MUST NOT appear with services of type http://oauth.net/core/1.0/endpoint/access.
- <oauth:RequestParameterMethods>
- 0 or 1 per Service element as defined in Section 5.3.6 (oauth:RequestParameterMethods Element). MUST be included in Service elements for the OAuth Endpoints, if the parent Realm Definition does not contain an oauth:RequestParameterMethods element.
- <oauth:RequestSignature>
- 0 or 1 per Service element as defined in Section 5.3.7 (oauth:RequestSignature Element). REQUIRED if the parent Realm Definition does not contain an oauth:RequestSignature element and the service type is http://oauth.net/core/1.0/endpoint/request, http://oauth.net/core/1.0/endpoint/access, or http://oauth.net/core/1.0/endpoint/resource.
| TOC |
The oauth:CustomParameters element is used to document Service Provider specific request parameters. Since [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) allows Service Providers to extent the list of parameters, the element provides the ability to list the parameters added. The element MUST NOT include OAuth Protocol Parameters or parameters implicitly defined by the inclusion of a service extension via a Type element as defined in Section 5.3.9 (Service Extensions).
The oauth:CustomParameters element contains 1 or more oauth:Parameter elements with type xs:string. The element MUST contain a source attribute with type xs:anyURI which indicates the source of the parameter definition.
| TOC |
The oauth:RequestParameterMethods element is used to document the request parameters methods supported by the Service Provider as defined in [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) section 5.2. Since [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) allows Service Providers to extent the list of supported methods, the element provides the ability to add methods that were not listed in the specification.
The oauth:RequestParameterMethods element contains 1 or more oauth:Method elements with type xs:string listed in decreasing preference. While [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) declares an order of preference, Service Providers MAY choose to override it, for example when adding new methods.
The oauth:Method element supports an OPTIONAL source attribute with type xs:anyURI which indicates the source of the method definition. If omitted, the source attribute defaults to http://oauth.net/core/1.0 which enables using the methods defined in [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) as values for the oauth:Method element: AUTH-HEADER, POST-BODY, and URL-QUERY.
The oauth:RequestParameterMethods element MAY be used in both the Realm Definition and Service elements. If present in both, the values of the child element are applied to the values of the parent element based on the OPTIONAL append attribute of the child's oauth:RequestParameterMethods element as defined in Section 5.3.8 (Append Attribute).
| TOC |
The oauth:RequestSignature element is used to document the signature methods supported by the Service Provider as defined in [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) section 9. Since [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) allows Service Providers to extent the list of supported methods, the element provides the ability to add methods that were not listed in the specification.
The oauth:RequestSignature element contains 1 or more oauth:Method elements with type xs:string listed in decreasing preference.
The oauth:Method element supports an OPTIONAL source attribute with type xs:anyURI which indicates the source of the signature method definition. If omitted, the source attribute defaults to http://oauth.net/core/1.0 which enables using the methods defined in [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) as values for the oauth:Method element: HMAC-SHA1, RSA-SHA1, and PLAINTEXT.
The oauth:RequestSignature element MAY be used in both the Realm Definition and Service elements. If present in both, the values of the child element are applied to the values of the parent element based on the OPTIONAL append attribute of the child's oauth:RequestSignature element as defined in Section 5.3.8 (Append Attribute).
| TOC |
The append attribute with type xs:string defines how two configuration lists are merged together into a single list in decreasing preference order. If the attribute is supported but omitted, it defaults to override. The attribute values are:
- override
- Only the child's values are used. The parent's values are ignored.
- head
- The values of the child and parent are merged with any duplicates removed from the parent's list. Preference is given to the child's values in their order and then to the remaining parent's values in their order. Child's values MAY be prefixed with an '!' character (ASCII code 33) indicating the value MUST be removed from both parent and child lists.
- tail
- The values of the child and parent are merged with any duplicates removed from the child's list. Preference is given to the parent's values in their order and then to the remaining child's values in their order. Child's values MAY be prefixed with an '!' character (ASCII code 33) indicating the value MUST be removed from both parent and child lists.
| TOC |
OAuth extensions MAY define additional service type URIs used to indicate support or property of an existing service type, or as a standalone service. The following example demonstrate using the http://oauth.net/example/language/1.0 URI to indicate the authorization endpoint supports a language parameter extension:
<Service> <Type>http://oauth.net/core/1.0/endpoint/authorize</Type> <Type>http://oauth.net/example/language/1.0</Type> <URI>https://api.example.com/session/login</URI> </Service>
Extensions to an OAuth Endpoint are OPTIONAL and MAY be used by the Consumer if supported. If an extension to an OAuth Endpoint is REQUIRED by the Service Provider, it MUST be identified using the oauth:required attribute. for example:
<Service> <Type>http://oauth.net/core/1.0/endpoint/authorize</Type> <Type oauth:required="true">http://oauth.net/example/language/1.0</Type> <URI>https://api.example.com/session/login</URI> </Service>
In the following example, a new service is defined which provides the Service Provider's terms of service:
<Service> <Type>http://oauth.net/example/tos/1.0</Type> <URI>https://api.example.com/tos</URI> <oauth:HttpMethod>GET</oauth:HttpMethod> </Service>
The oauth:Method and oauth:HttpMethod elements provide extendibility through the source attribute which also uses URIs to identify the type of extension used. If the Consumer is unfamiliar with the value of the source attribute, it SHOULD look for other familiar methods listed. In order to use existing specifications that do not define a namespace URI, the official specification URL SHOULD be used when possible. For RFCs, the URI is the RFC number prefixed by http://www.ietf.org/rfc/rfc.
In this example, the Service Provider's terms of service are available using the WebDAV HTTP method PROPFIND:
<Service> <Type>http://oauth.net/example/tos/1.0</Type> <URI>https://api.example.com/tos</URI> <oauth:HttpMethod source="http://www.ietf.org/rfc/rfc4918">PROPFIND</oauth:HttpMethod> </Service>
| TOC |
Parsing the Discovery Definition Document includes the following steps:
| TOC |
The Consumer SHOULD check to see if it already has a valid Consumer Identity for the discovered Consumer Realm of the Protected Resource. If true, the Consumer MAY use that identity. In this case, the Consumer does not need to discover or parse the Realm Definition of the Consumer Realm.
If the Consumer does not have a valid Consumer Identity, it MUST use the discovered information contained in the Realm Definition of the Consumer Realm to obtain an identity.
[OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) requires Consumers to establish an Consumer Identity prior to making OAuth requests, and leaves the methods of establishing the Consumer Identity unspecified. The process of establishing a Consumer Key and Consumer Secret can be complex and can also require manual human interaction for legal, compliance, and other reasons. However, there are some cases in which a simple Consumer Identity is sufficient or not needed at all.
OAuth Discovery defines three Consumer Identity allocation scenarios: static, dynamic, and manual.
| TOC |
Static Consumer Identity allocation is used when no Consumer Identity is needed. In this case the Service Provider does not desire tracking individual Consumers, or might provide limited accessibility to unidentified Consumers. In this scenario, the Service Provider assigns a default Consumer Identity in the Realm Definition of the Consumer Realm.
Static allocation is identified using the service type URI: http://oauth.net/discovery/1.0/consumer-identity/static. The Realm Definition MUST include a Service element with the type URI and an oauth:ConsumerKey element with the Consumer Key encoded per [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) section 5.1. Static allocation does not include a Consumer Secret which is an empty string. For example:
<Service> <Type>http://oauth.net/discovery/1.0/consumer-identity/static</Type> <oauth:ConsumerKey>0685bd9184jfhq22</oauth:ConsumerKey> </Service>
| TOC |
Dynamic Consumer Identity allocation is used when a basic Consumer profile is needed. The Service Provider allows Consumer to automatically apply and receive a Consumer Identity by providing some information. In this scenario, the Service Provider provides an endpoint the Consumer uses to request a Consumer Identity with a simple set of parameters to establish identity.
Dynamic allocation is identified using the service type URI: http://oauth.net/discovery/1.0/consumer-identity/dynamic. The Realm Definition MUST include a Service element with the type URI, URI element, and oauth:HttpMethod element. The Service element MAY include the OPTIONAL oauth:RequestParameterMethods and oauth:CustomParameters elements. The HTTP response of the request uses [OAuth Core 1.0] (OAuth, OCW., “OAuth Core 1.0,” .) section 5.3 and include the oauth_consumer_key and xoauth_consumer_secret parameters. For example:
<Service> <Type>http://oauth.net/discovery/1.0/consumer-identity/dynamic</Type> <URI>http://sp.example.com/register</Type> <oauth:HttpMethod>GET</oauth:HttpMethod> <oauth:RequestParameter> <oauth:Method>URL-QUERY</oauth:Method> </oauth:RequestParameter> <oauth:CustomParameters> <oauth:Parameter source="http://oauth.net/example/consumer_identity>name</oauth:Parameter> <oauth:Parameter source="http://oauth.net/example/consumer_identity>description</oauth:Parameter> <oauth:Parameter source="http://oauth.net/example/consumer_identity>url</oauth:Parameter> </oauth:CustomParameters> </Service>
| TOC |
Manual Consumer Identity allocation is used when the Service Provider requires a Consumer registration process that cannot be performed automatically or has unique requirements the Consumer Developer needs to address. OAuth Discovery does not address this scenario expect for enabling the Service Provider to provide a human-readable endpoint, and associating Consumer Identities obtained via that endpoint to a Consumer Realm. This allows Consumer to use OAuth Discovery with manually pre-established Consumer Identities. Type:
Manual allocation is identified using the service type URI: http://oauth.net/discovery/1.0/consumer-identity/manual. The Realm Definition MUST include a Service element with the type URI, URI element, and oauth:HttpMethod element. The result value of the request is undefined. For example:
<Service> <Type>http://oauth.net/discovery/1.0/consumer-identity/manual</Type> <URI>http://sp.example.com/consumer_apply</Type> <oauth:HttpMethod>GET</oauth:HttpMethod> </Service>
| TOC |
In cases where a Service Provider offers multiple Consumer Realms, and allows access to its Protected Resources using different combinations of those Realms, the Service Provider MAY include multiple Consumer Realms per Resource Realm. The Service Provider MAY also include multiple Consumer Identity services for a single Consumer Realm, allowing Consumers to use one of multiple methods to obtain a Consumer Identity.
| TOC |
The Consumer SHOULD check to see if it already has a valid Access Token for the discovered User Realm of the Protected Resource. If true, the Consumer MAY use that Token together with the Consumer Identity established in the previous step to access the Protected Resource. In this case, the Consumer does not need to discover or parse the Realm Definition of the User Realm.
If the Consumer does not have a valid Access Token, it MUST use the discovered information contained in the Realm Definition of the User Realm to perform the OAuth protocol and obtain access. The Realm Definition contains all the documentation required to successfully complete the Oauth workflow.
| TOC |
The examples in this section demonstrate some of the capabilities of the OAuth Discovery and try to provide a usable template for both simple and complex scenarios.
| TOC |
This example demonstrate a Discovery Definition Document where the Resource Realm contains the services configuration for both the User Realm and Consumer Realm. The Service Provider also support static Consumer Identity allocation.
<?xml version="1.0" encoding="UTF-8"?> <XRDS xmlns="xri://$xrds"> <XRD xmlns:oauth="http://oauth.net/discovery/1.0" xmlns="xri://$xrd*($v*2.0)"> <Query>http://api.example.com/</Query> <Expires>2007-12-31T23:59:59Z</Expires> <oauth:RequestParameterMethods> <oauth:Method>AUTH-HEADER</oauth:Method> <oauth:Method>POST-BODY</oauth:Method> <oauth:Method>URL-QUERY</oauth:Method> </oauth:RequestParameterMethods> <oauth:RequestSignature> <oauth:Method>HMAC-SHA1</oauth:Method> </oauth:RequestSignature> <Service> <Type>http://oauth.net/core/1.0/endpoint/request</Type> <URI>https://api.example.com/session/request</URI> <oauth:HttpMethod>POST</oauth:HttpMethod> <oauth:RequestSignature append="head"> <oauth:Method>PLAINTEXT</oauth:Method> </oauth:RequestSignature> </Service> <Service> <Type>http://oauth.net/core/1.0/endpoint/authorize</Type> <URI>https://api.example.com/session/login</URI> <oauth:RequestParameterMethods append="override"> <oauth:Method>URL-QUERY</oauth:Method> </oauth:RequestParameterMethods> </Service> <Service> <Type>http://oauth.net/core/1.0/endpoint/access</Type> <oauth:HttpMethod>POST</oauth:HttpMethod> <URI>https://api.example.com/session/activate</URI> <oauth:RequestSignature append="head"> <oauth:Method>PLAINTEXT</oauth:Method> </oauth:RequestSignature> </Service> <Service> <Type>http://oauth.net/discovery/1.0/consumer-identity/static</Type> <oauth:ConsumerKey>0685bd9184jfhq22</oauth:ConsumerKey> </Service> </XRD> </XRDS>
| TOC |
| [OAuth Core 1.0] | OAuth, OCW., “OAuth Core 1.0.” |
| [RFC2119] | Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119. |
| [RFC2606] | Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” RFC 2606. |
| [RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616. |
| [RFC2617] | Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617. |
| [SHA1] | De Canniere, C. and C. Rechberger, “Finding SHA-1 Characteristics: General Results and Applications.” |
| [XRI Resolution 2.0] | Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0 - Committee Draft 02” (HTML, PDF). |
| TOC |
| Eran Hammer-Lahav | |
| Hueniverse, LLC | |
| Email: |<EMAIL_ADDRESS>|


Chalk CSS
Simple and clean.
Chalk CSS is a lightweight css framework that allows you to make your website look clean and simple. It has a simple grid system and uses soft font types and colors. If you need a simple and clean looking site, then this is the perfect framework for you. Get Chalk CSS now by following the guide below.
Clone the project from github:
$ git clone https://github.com/rowanryan/chalkcss.git
The grid system is simple. To use the grid system, you first need a row. You will be able to make columns in that row. The grid is divided in 12 parts and each column can take up multiple parts.

.col col-3

.col col-6

.col col-3

.col col-3
.col col-6
.col col-3
As you can see, you can use the grid however you like. Do keep in mind that a row can only hold 12 parts. That means that you have to start a new row if you've used up all 12 parts in one row. Below, you will find an example.
1
11
2
10
3
9
4
8
5
7
6
6
7
5
8
4
9
3
10
2
11
1
To flourish up your text, make use of the classes below.
.size-1
.size-2
.size-3
.size-4
.size-5
.size-6
.primary
.info
.danger
.success
.tip
The color of text can only be changed if it's wrapped by a h1, h2, h3, h4, h5, h6, p, a or span.
Cards are simple objects that can be used to display information. A good use-case for a card would be to show an item in a webshop.

Title

Lorem ipsum dolor sit amet consectetur adipisicing elit. Accusantium esse voluptate nesciunt eligendi quod consequuntur iste corrupti pariatur.

<button class="btn btn-primary">Add</button>

Lorem ipsum dolor sit amet consectetur adipisicing elit. Accusantium esse voluptate nesciunt eligendi quod consequuntur iste corrupti pariatur.
Forms are an essential part of every CSS framework. Chalk CSS keeps it simple and clean. Every group of inputs are wrapped by a form field. Form fields are made by adding form-field as a class to a div. Inline fields are also available. To make a field inline, add the inline class to the form field. Inputs must always have the class input assigned to have the styling applied.
<form class="form">

<input type="text" class="input" placeholder="Name">
<input type="email" class="input" placeholder="Email">

</form>
<form class="form">

<input type="text" class="input" placeholder="Name">
<input type="email" class="input" placeholder="Email">

</form>
<form class="form">

<textarea class="textarea" cols="50" rows="10"></textarea>

</form>
<form class="form">

<select class="select">
<option disabled>Option 1</option>
<option>Option 2</option>
<option>Option 3</option>
</select>

</form>
Tables are the easiest way to display structured data. All you need to do is assign the class table to the main table element.
| Name | Alias | Height | Comics universe |
|---|---|---|---|
| Bruce Wayne | Batman | 6'2" (188 cm) | DC Comics |
| Peter Parker | Spiderman | 5'10" (178 cm) | Marvel |
You can also add the bordered class to the main table element to surround the table with a border.
| Name | Alias | Height | Comics universe |
|---|---|---|---|
| Bruce Wayne | Batman | 6'2" (188 cm) | DC Comics |
| Peter Parker | Spiderman | 5'10" (178 cm) | Marvel |
In addition to adding the bordered class to the main element, you can add bordered to each seperate row.
| Name | Alias | Height | Comics universe |
|---|---|---|---|
| Bruce Wayne | Batman | 6'2" (188 cm) | DC Comics |
| Peter Parker | Spiderman | 5'10" (178 cm) | Marvel |
All you need to do to make a list is add the list class to a ul or ol element. Each list item takes the class list-item . To make a list-item active, add the active class.

list-item

list-item active

list-item

A notification is a handy little object to notify your visitors of something. Add the notification class to a div for the styling to appear. You can add a color to the notification by adding one of the color classes to the notification.

Your subscription has expired! Click
here
to renew your subscription

Your subscription has expired! Click here to renew your subscription
Your subscription has expired! Click here to renew your subscription
Your subscription has expired! Click here to renew your subscription
Your subscription has expired! Click here to renew your subscription
Your subscription has expired! Click here to renew your subscription


Full stack NodeJS course at Computer Science, KEA, 2020
This site is a product of the Mandatory 1 assignment in NodeJS.
@Author: Rasmus Knoth Nielsen


Using the Push Notifications Mobile Service
- Push Notifications Terminology
- Setting Up the Push Notifications Mobile Service
- Configuring your client app
- Registering device on Push Notifications Service
- Sending a Push Notification using the Unified Push Admin UI
- Handling Incoming Push Notifications
- Unregistering device on Push Notifications Service
The Push Notifications service allows you to send native push notifications to different mobile operating systems.
-
Code once and push notifications to iOS and Android.
-
Push notifications to defined groups.
-
Push notifications to either iOS only or Android only.
-
Push notifications to different variants of a mobile app.
-
Push notifications from different back-end apps to the same mobile app.
Currently the service supports:
The Push Notifications service offers a unified Notification Service API to the above mentioned Push Network Services. It can be seen as a broker that distributes push messages to different 3rd party Push Networks.
|
-
You understand Push Notifications.
-
You have logged into the OpenShift console and the Mobile Developer Console.
Push Notifications Terminology
This section describes terminology that is associated with Push Notifications.
- Push Application
-
A logical construct that represents an Mobile App, for example, Mobile HR.
- Push Notification Message
-
A simple message to be sent to a Push Application.
- Sender Endpoint API
-
A RESTful API that receives Push Notification Message requests for a PushApplication or some of its different Variants. The Server translates this request into the platform specific details and delivers the payload to the 3rd party cloud providers, which eventually might deliver the message to the physical device.
- Variant
-
A variant of the Push Application, representing a specific mobile platform, like iOS or Android, or even more fine-grained differentiation like iPad or iPhone. There can be multiple variants for a single Push Application (for example, Mobile HR Android, Mobile HR iPad, Mobile HR iOS free or _Mobile HR iOS premium). Each supported variant type contains some platform specific properties, such as a Google API key (Android) or passphrase and certificate (Apple).
- APNs
- Installation
-
Represents an actual device, registered with the UnifiedPush Server. User1 running HR Android app, while User2 runs HR iPhone premium on his phone.
- Administrative User Interface
-
(AUI) The Unified Push Admin UI Web UI that allows you manage Push Applications and Variants, view statistics and send Push Notifications to devices.
Setting Up the Push Notifications Mobile Service
Obtaining Firebase Cloud Messaging Credentials
This procedure describes how to obtain Firebase Cloud Messaging Credentials.
Before the Android application is able to receive the notifications, you must set up access to Firebase Cloud Messaging. The following credentials are necessary to set up Firebase Cloud Messaging for your app:
-
Server key
-
Sender ID
-
google-services.json
file containing the credentials required to connect your app to Firebase and Google services.
-
From the Project Settings screen, switch to the Cloud Messaging tab, where you can find the Server key and Sender ID (known in GCM as Project Number). There is also a Legacy server key but it should not be used for new projects.
-
Download the
google-services.json
file as described in the Google Documentation.
Obtaining Apple Push Notification Service Credentials
This procedure describes how to enable Push Notifications for your iOS application and get the credentials required for push from Apple.
-
Follow the official Apple guide to enable push notifications for your Xcode project.
-
Follow the official Apple guide to generate an APNs client TLS certificate and export the client TLS identity from your Mac.
Make sure to protect the p12 file with a password.
The exported p12 file with the password will be used later when binding your Mobile App to the Push Notifications.
Provisioning the Push Notifications Service
This section describes how to set up the Push Notifications Mobile Service.
-
Log into the OpenShift console.
-
Create a new project or choose an existing project.
-
Click Add to Project and choose Browse Catalog from the options.
You can filter the catalog items to only show mobile specific items by clicking the Mobile tab.
-
Click Services and choose the service.
-
Follow the wizard for provisioning that service.
If prompted to Create a Binding, choose Do not bind at this time
Once the wizard steps are completed, navigate to the Project Overview in OpenShift to see the newly provisioned service. Provisioning a service may take some time.
Binding a Mobile App with the Push Notifications Service
To use mobile services, you must represent your mobile app in Mobile Developer Console, and that app must be associated with the mobile service. This association is called binding and it is necessary for your mobile app to use that service.
-
You have created a Mobile App.
-
Google account
-
Access to the Firebase console. Refer to Firebase Docs.
-
Apple Developer account
-
APNs client TLS certificate. Refer to official Apple guide.
To bind a Mobile App with a mobile service:
-
Log in to the Mobile Developer Console.
-
Click on the Mobile App on the Overview screen.
-
Navigate to Mobile Services tab.
It is possible to bind a Mobile App with a mobile service in the OpenShift console, however such bindings are not valid for the purposes of this procedure. -
Press Bind to App in the Push Notifications.
-
Fill out the binding parameters required by the Push Notifications Service.
When you bind a mobile client to the Push Notifications service, a variant is created to store the credentials required to communicate with a push network. Those credentials need to be provided in the binding dialog.
Choose a Mobile Client Type and fill out the required fields:
-
Select
Android
from in theMobile Client Type
list. -
Enter a Server Key and a Sender ID. Both are present in the Firebase console.
-
Select
iOS
from theMobile Client Type
list. -
Obtain an APNs client TLS certificate. Refer to official Apple guide.
-
Encode the certificate using base64 and paste the encoded certificate into the field labeled
iOS .p12 file
.If you are using macOS:
cat <path/to/your/.p12> | base64
If you are using Linux and a version of
base64
that wraps lines, disable line wrapping as follows:cat <path/to/your/.p12> | base64 --wrap=0
After clicking Create your variant will be created in UPS and you should see a new binding for your mobile client. A variant is used for the storage of the credentials provided in the Binding procedure.
-
Configuring your client app
Downloading the Configuration File
The mobile-services.json
file provides the information for your mobile app to communicate with services.
After you change any configuration in the Mobile Developer Console, it is important to update that file in your IDE.
-
The configuration of your Mobile App in Mobile Developer Console is up-to-date.
-
You have set up your mobile app development environment.
-
Open your Mobile App in Mobile Developer Console.
-
Copy the
mobile-services.json
configuration to your clipboard. -
Save the contents of the clipboard to a new file called
mobile-services.json
.The mobile-services.json
file is the link between your provisioned services on OpenShift and the mobile app you are developing. This file provides all required configuration to initialise the various SDKs and get them hooked up/connected to the back-end services. -
Move
mobile-services.json
to the following location in your application project:app/src/main/assets/mobile-services.json
<app directory>/mobile-services.json
NOTE: Ensure thatmobile-services.json
is a member of the project in the Xcode Project Navigator.src/mobile-services.json
To run the Cordova app on the Android device you also need to download the google-services.json
from Firebase and put it on the root folder of your project.Resources/mobile-services.json
Setting up the Push Notifications Service SDK
This section helps you to set up the Push Notifications service SDK in your App. It describes how to set up and initialize the Push Notifications service SDK.
-
Your local
mobile-services.json
file is up-to-date.
An APNs service.
-
Import the libraries
-
Add the push dependency to your application module
implementation "org.aerogear:aerogear-push:1.0.0" implementation "com.google.firebase:firebase-messaging:[version]"
-
Create a new project in Firebase console
-
Add The Google Services Gradle Plugin in your root
build.gradle
filebuildscript { dependencies { classpath 'com.google.gms:google-services:[version]' } }
-
Apply the plugin in your app
build.gradle
file// ADD THIS AT THE BOTTOM apply plugin: 'com.google.gms.google-services'
-
Add the dependency to your Podfile
target '[TARGET NAME]' do pod 'AGSPush', '[VERSION]' end
-
Update the dependencies
$ pod install
-
Import the SDK
import AGSPush
-
Install
cordova-plugin-aerogear-push
:$ cordova plugin add @aerogear/cordova-plugin-aerogear-push
-
Install the Unified Push Server package needed for device registration:
$ npm install --save @aerogear/push
This feature is not yet supported in the AeroGear Xamarin SDK
-
Registering device on Push Notifications Service
To receive native push notifications from a Push Network, for example APNs or FCM, the mobile device is identified with a unique device-token assigned by that Push Network. This device-token is passed, by the operating system, to the mobile application. Refer to the operating system and Push Network documentation for further details.
Every time a user launches a mobile app, that app receives the device-token
, from a platform-specific method (or callback).
Since the Push Network may assign a new token to a device, AeroGear recommends that the app registers the device-token
with the UnifiedPush Server each time.
The required metadata for an Installation
:
-
deviceToken: _Identifies the device/user-agent within its Push Network.
-
variantID: The ID of the variant, where the client belongs to
-
variantSecret: Password of the actual variant
The AeroGear UnifiedPush Server is able to store some user-specific metadata as well:
-
deviceType: The device type of the device or the user agent.
-
operatingSystem: The name of the underlying Operating System.
-
osVersion: The version of the used Operating System.
-
alias: Application specific alias to identify users with the system. For instance an
email address
or ausername
. -
categories: Used to apply one or more "tags".
The device-token needs to be registered with the AeroGear UnifiedPush Server, to indicate there is a new Installation for a Variant. This registration is performed by calling an endpoint of the server.
-
Getting an instance of the PushService
PushService pushService = new PushService.Builder().openshift().build();
-
Registration request
pushService.registerDevice() .requestOn(new AppExecutors().mainThread()) .respondWith(new Responder<Boolean>() { @Override public void onResult(Boolean value) { // Yay } @Override public void onException(Exception exception) { // Oops! } });
func application(_ application: UIApplication,
didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
var config = UnifiedPushConfig()
AgsPush.instance.register(
deviceToken,
config,
success: {
print("Successfully registered to Unified Push Server")
},
failure: { (error: Error!) in
print("Failure to register for on Unified Push Server: \(error)")
}
)
}
import { PushRegistration } from "@aerogear/push";
new PushRegistration(app.config).register().then(() => {
// Registration with UPS successful, you can now send push notifications from the UPS UI
}).catch(err => {
// Error on device registration
});
| Optionally, you can pass the parameters below to the register method |
{
alias: 'some-alias',
categories: ['one', 'or', 'more', 'categories'],
timeout: 5000 // in milliseconds
}
curl -u "variantID:variantSecret" \
-v -H "Accept: application/json" -H "Content-type: application/json" \
-H "aerogear-push-id: someid" \
-X POST https://SERVER:PORT/context/rest/registry/device/ \
-d '{ \
"deviceToken" : "<deviceToken>", \
"deviceType" : "<deviceType>", \
"operatingSystem" : "<operatingSystem>", \
"osVersion": "<osVersion>", \
"alias" : "username or email", \
"categories" : ["example1", "example2"] \
}'
The variant ID and variant secret can be found on the push application page. If you are using firebase, you also must subscribe to a topic of the variantID, and each of the categories in the registration request using the subscribeToTopic method. More information about that can be found here for android, and here for web.
This feature is not yet supported in the AeroGear Xamarin SDK
Sending a Push Notification using the Unified Push Admin UI
The Unified Push Admin UI allows you to send Push Notifications.
-
Make sure the Push Notifications service is provisioned.
-
Select a route in OpenShift.
-
Login with your OpenShift credentials.
| On first login you need to provide the OpenShift OAuth service permissions to read your user account. |
-
Open the Unified Push Admin UI in a browser.
-
Select the target application from the home page and click Send Notification To This App.
-
When the Send Push dialog displays, enter text in the Message form.
-
Click Send Push Notification to send the message to the target application.
-
Add unifiedpush-java-client as a dependency to your project.
<dependency> <groupId>org.jboss.aerogear</groupId> <artifactId>unifiedpush-java-client</artifactId> <version>[version]</version> </dependency>
-
Send the message to the target application.
final PushSender sender = DefaultPushSender .withRootServerURL("<pushServerURL e.g http(s)//host:port/context>") .pushApplicationId("<pushApplicationId e.g. 1234456-234320>") .masterSecret("<masterSecret e.g. 1234456-234320>") .build(); final UnifiedMessage unifiedMessage = UnifiedMessage .withMessage() .alert("Hello from Java Sender API!") .build(); sender.send(unifiedMessage, () -> { //do cool stuff });
-
Add unifiedpush-node-sender as a dependency to your project.
npm i unifiedpush-node-sender
-
Send the message to the target application.
const agSender = require('unifiedpush-node-sender'); const settings = { url: "<pushServerURL e.g http(s)//host:port/context>", applicationId: "<pushApplicationId e.g. 1234456-234320>", masterSecret: "<masterSecret e.g. 1234456-234320>" }; const message = { alert: "Hello from the Node.js Sender API!" }; const options = { config: { ttl: 3600 } }; agSender(settings).then((client) => { client.sender.send(message, options).then((response) => { console.log('success', response); }).catch((error) => { console.log('error', error); }) });
-
Send the message to the target application.
curl -u "<pushApplicationId>:<masterSecret>" \ -v -H "Accept: application/json" -H "Content-type: application/json" \ -X POST -d \ '{ "message": { "alert": "Hello from the curl HTTP Sender!", "sound": "default" } }' \ <pushServerURL>/rest/sender
| The 3rd party Push Network is responsible for delivering the Push Notification to the target application. |
Handling Incoming Push Notifications
This section describes how to handle incoming push notifications in your foregrounded application.
| Push notifications that arrive when the application is in the background are always handled by the OS. |
Add to your project an implementation of MessageHandler:
public class MyMessageHandler implements MessageHandler {
@Override
public void onMessage(Context context, Map<String, String> message) {
// Handle incoming message
}
}
Add it to your application’s manifest.
<meta-data
android:name="DEFAULT_MESSAGE_HANDLER_KEY"
android:value=".MyMessageHandler" />
The AeroGear SDK for iOS does not provide a way to handle incoming messages. Instead, follow the Apple’s official documentation about notifications.
Add the following code to your app:
import { PushRegistration } from "@aerogear/push";
PushRegistration.onMessageReceived((notification: any) => {
console.log('Received a push notification', notification);
});
This feature is not yet supported in the AeroGear Xamarin SDK
Unregistering device on Push Notifications Service
This section describes how to unregister devices.
-
Getting an instance of the PushService
PushService pushService = new PushService.Builder().openshift().build();
-
Registration request
pushService.unregisterDevice() .requestOn(new AppExecutors().mainThread()) .respondWith(new Responder<Boolean>() { @Override public void onResult(Boolean value) { // Yay } @Override public void onException(Exception exception) { // Oops! } });
This feature is not yet supported in the AeroGear iOS SDK
import { PushRegistration } from "@aerogear/push";
new PushRegistration(app.config).unregister().then(() => {
// Unregistering was a success.
}).catch(err => {
// Error on device registration
});
curl -u "variantID:variantSecret" \
-v -H "Accept: application/json" -H "Content-type: application/json" \
-X DELETE \
https://SERVER:PORT/context/rest/registry/device/{deviceToken}
If you are using firebase, you also must unsubscribe to a topic of the variantIDS, and each of the categories the device is subscribed to.
This feature is not yet supported in the AeroGear Xamarin SDK


What is this place?
This is howler.space, home of the definitive, unofficial, and only
imageboard for NC State university. As this is the the only
imageboard created explicitly for collegiate discourse, I recommend
that you learn the ropes to make the most of this opportunity!
Anonymous ## Admin
Help, I have never used a liveboard/imageboard!
before
You're not alone! A lot of people have never posted to an
imageboard before, but I'm here to help you out!
 Make small-talk before you start a thread
about something that interests you!
Secondly, don't be discouraged if the conversation is slow.
Finally, since this is an imageboard, posting images is highly
encouraged!
Subsection of an imageboard where discussion is focused on
one specific topic such as school or food
Liveboard
A type of imageboard which operates in real-time. This means
people can read your post and talk with you as
you type, like a real-life conversation on the internet!
There are a lot of neat commands that you can issue -- here are only
a few of them
Wrap text in [spoiler]to hide it![/spoiler]Spoiler images by clicking on the spoiler pane at the bottom
of the reply boxTo quote text, prepend your message with >To reply to someone, click their post number#fortune (Many will travel to hear you
speak.)#future (Study Hard!)#d100 (90)


| < Day Day Up > |
11.1 Rule-Based System BasicsRule-based systems have two main components: the working memory and the rules memory. The working memory stores known facts and assertions made by the rules. The rules memory, or rules, for short, contains if-then style rules that operate over the facts stored in working memory. As rules are triggered, or fired in rule-based system lingo, they can trigger some action or state change, such as in a finite state machine, or they can modify the contents of the working memory by adding new information called assertions. Example 11-1 shows how the working memory for a real-time, strategy-game technology tree might look. Example 11-1. Example working memoryenum TMemoryValue{Yes, No, Maybe, Unknown}; TMemoryValue Peasants; TMemoryValue Woodcutter; TMemoryValue Stonemason; TMemoryValue Blacksmith; TMemoryValue Barracks; TMemoryValue Fletcher; TMemoryValue WoodWalls; TMemoryValue StoneWalls; TMemoryValue Cavalry; TMemoryValue FootSoldier; TMemoryValue Spearman; TMemoryValue Archer; TMemoryValue Temple; TMemoryValue Priest; TMemoryValue Crossbowman; TMemoryValue Longbowman; For this example, we made each element in working memory a TMemoryValue type that can take on any one of four values: Yes, No, Maybe, or Unknown. The idea here is to keep track of the computer opponent's current perception of the state of technology of the player opponent. A value of Yes implies that the player has the particular technology, whereas a value of No implies that she does not. If the player meets all the criteria to gain or posses a certain technology, but the state has yet to be confirmed by a scout, the value of Maybe is used. If the computer knows nothing about a particular technology capability for the player, Unknown is used. The computer can gather facts on the player's current state of technology by sending out scouts and making observations. For example, if the computer sends out a scout and sees that the player has built a temple, Temple would be set to Yes. Using a set of if-then style rules, the player can infer the state of technology for the player, before a scout confirms it, given some known facts. For example, referring to Figure 11-1, if the player has woodcutters and stonemasons, she is capable of having a temple. In this case, Temple is set to Maybe. A rule for this scenario might look like that shown in Example 11-2. Example 11-2. Example temple ruleif(Woodcutter == Yes && Stonemason == Yes && Temple == Unknown) Temple = Maybe; Inference can work the other way as well. For example, if the player has been observed to have a priest, the computer can infer that the player also must have a temple, and therefore also must have a barracks, a woodcutter, and a stonemason. A rule for this scenario might look like that shown in Example 11-3. Example 11-3. Example priest ruleif(Priest == Yes) { Temple = Yes; Barracks = Yes; Woodcutter= Yes; Stonemason= Yes; } You can have many more rules for this type of technology tree. Example 11-4 shows a handful of other rules you can write. Example 11-4.  You can develop several more, covering all possible technologies shown in Figure 11-1. The idea here is that you can write such rules and execute them continuously during the game—that is, each iteration through the game loop—to maintain an up-to-date picture of the computer opponent's view of the player's technology capabilities. In this example, the computer can use this knowledge in other AI subsystems to decide how to deploy its attack forces and defenses. This example should give you a basic idea of how a rule-based system works. It really comes down to a set of if-then style rules and a set of facts and assertions. Note, however, that very often developers do not build rule-based systems using actual if-statements such as those shown in this section. We discuss alternatives a little later, but basically hardcoding the if-statements makes a certain type of inference hard to achieve. Further, developers often use scripting languages or shells so that they can create and modify rules without having to change source code and recompile. 11.2.1 Inference in Rule-Based SystemsIn the previous section we took a look at the main components of rule-based systems and showed how you can use such a system to make inferences in a real-time strategy game. In this section we're going to take a slightly more formal look at making inferences using rule-based systems. Our aim here is to distinguish between the two basic algorithms for making inferences and to introduce some standard rule-based system lingo in case you decide to dig further in the technical literature for more information on rule-based systems. (We give some references at the end of this chapter.) 11.2.1 Forward ChainingThe most common inference algorithm for rule-based systems is called forward chaining. This algorithm consists of three basic phases. The first phase involves matching rules to facts stored in working memory. You do this by checking the if-parts of each rule to see if they match the given set of facts or assertions in working memory. For example, in our technology tree example, if the working memory indicates that Peasants = Yes and Woodcutter = Unknown, we know the first rule shown in Example 11-4 matches and potentially can be fired. When a rule is fired, its then-part is executed. Potentially, more than one rule can match a given set of facts in working memory. In this case, we have to figure out which rule to fire. This leads to the so-called conflict resolution phase. In the conflict resolution phase we have to examine all the matching rules and figure out which one we want to fire. We can make this decision in many ways. A common approach is to fire the first matching rule. Sometimes you can pick one at random. In other cases, the rules are weighted and the one with the highest weight is selected. We're going to take this latter approach in our fighting example. After the conflict resolution phase is executed and a rule is selected, we fire the rule. Firing a rule simply means executing its then-part. The rule might assert some new facts in working memory, such as in the rules in Example 11-4. It might trigger some event or call some other function that does some sort of processing. After these three phases are executed, the whole process is repeated until no more rules can be fired. When this happens the working memory should contain everything the rule-based system can infer given the starting facts. Don't worry if this is a bit nebulous at this point. Things will become clearer when we get to the fighting example. 11.2.2 Backward ChainingBackward chaining is sort of the opposite of forward chaining. We still have working memory and rules memory, but instead of trying to match if-parts of rules to working memory, we try to match the then-parts. In other words, in backward chaining we start with some outcome, or goal, and we try to figure out which rules must be fired to arrive at that outcome or goal. Consider the technology tree example one more time. Let's say the outcome is that the player has cavalry units—that is, Cavalry = Yes. To figure out how the player arrived at acquiring cavalry we can backward-chain to see which rules must be fired to set Cavalry to Yes. Looking at Figure 11-1, we see that to have cavalry, the player must have had a blacksmith. A rule for this situation might look like the code shown in Example 11-5. Example 11-5. Cavalry ruleif(Blacksmith == Yes) Cavalry =Yes Continuing, if the player has a blacksmith, she must have had barracks. If the player had barracks, she must have had a woodcutter, and so on. We can continue this sort of logic backward up the technology tree from the goal, Cavalry = Yes, through all the rules and facts that are required to arrive at that goal. This is backward chaining. In practice, backward chaining is recursive and more difficult to implement than forward chaining. Further, hardcoding if-statements such as those in our illustrative examples makes it difficult to match the then-parts of rules to facts stored in working memory during backward chaining. In the fighting example, we'll look at how to implement rule-based systems without actually hardcoding if-then style rules. |
| < Day Day Up > |


A basic slider
Add some color
With a pre-set value
With different bounds
A slider fires a change event during a drag and a commit event when the drag finishes.


California Office of Digital Innovation
Government services, programs, rules, and operations too often serve the process not the people. That’s why Governor Gavin Newsom created the Office of Digital Innovation (ODI). We use people-centered design and technology to reimagine and deliver equitable, effective services to Californians. Better serving people starts with understanding their needs, challenges and expectations.
We’re hiring
ODI is looking for creative and inspired people committed to making state government more accessible and effective for all Californians. We’re currently recruiting for:
If this opportunity does not match your skill set, but you’re still interested in joining the team, send us your resume.
What we do
We focus on creating and delivering lasting change, not just quick fixes. We work with state agencies and departments to reimagine the core processes, technology systems, and policies that problems are rooted in.
Create solutions
Build intuitive digital solutions like websites, data systems, and APIs, that make it easier to access state services.
More accessibility
Redesign how the state shows information, so all Californians can use it, understand it and get the resources they need.
Prototype services
Envision solutions that anticipate Californians’ needs and help them get assistance quickly and with minimal effort.
Raise empathy
Gather and share data and insights about Californians’ needs and challenges to improve programs and policy.
Improve equity
Identify and eliminate inequity, exclusion, and bias in state program requirements, policies, and technical systems.
Build capacity
Equip state workers with the training and tools they need to understand people’s needs and create better services.
Drive efficiencies
Streamline state processes by eliminating redundancy, automating steps and reducing paper-to-digital transfer.
Frame priorities
Focus leaders’ attention on those issues and problems that matter most to Californians and recommend solutions.
Safeguard rights
Encourage data portability, collaboration, and transparency while protecting Californians’ security and privacy.
Who we are
We hire and develop cross-discipline staff with blended backgrounds in tech, design, data, policy, strategy, and research. Our team comes from within the public and private sector. We understand the intricacies of government services and programs. We bring empathy, curiosity, data, technology, and a host of other tools to identifying and solving problems.
- Udaya Patnaik, Director
- Anne Neville-Bonilla, Chief Deputy Director
- Chad Bratton, IT Supervisor
- Angelica “Angie” Quirarte, Deputy Director, Projects
- Debra Waltman, Administration Chief
- Aaron Hans, Senior Developer
- JP Petrucione, Deputy Director, Communications and Insights
- Britt Allen, Performance Analyst
- Jim Bumgardner, Full Stack Developer
- Christian Crumlisch, Product Manager
- Peggy Gartin, Content Designer
- Clara Gonzalez Sueyro, User Researcher
- Dave Guarino, Product Lead
- Konstantin Koryaka, Full Stack Developer
- Justin Lai, User Researcher
- Hannah Lee, Product Lead
- Adam Little, Designer
- Laura Littlefield, Administration
- Jessica Lopez, Executive Fellow
- Jeffery Marino, Insights Product Lead
- Carter Medlin, Full Stack Developer
- Jenn Moran, Deputy Director, Talent
- Rebecca Sanjabi, Data Engineer
- Chach Sikes, Full Stack Developer
- Michael Sullivan, Content Designer
- Dana Chisnell, Content Designer (alumnus)
- Oriel Gomez, Fellow (alumnus)
- Hillary Hoeber, User Researcher (alumnus)
- Eric Hysen, Project Lead (alumnus)
- Artem Khomishen (alumnus)
- Corey Mahoney, Content Designer (alumnus)
- Jen Tress, Recruitment and Talent Lead (alumnus)
California needs you
If you’re interested in building solutions to help solve problems like COVID-19 vaccine distribution, homelessness, wildfires or any of the many issues facing California today:
Join our team


Bug: Jumping to first move does not remove last move mark
Ticket 106 at GitHub
. How to show who is to move.
Example game
Go to move 3
Then press "First Move" button.


 But I’m an optimist and a firm believer in Sturgeon’s Law so by that logic there must be some good on it. That good is academic twitter.
While this isn’t a post advocating for academic Twitter, I did want to
- see if I could figure out how to write a post with some R code in it and 2. share how I scraped Twitter to find active users in the Musicology and Music Theory community


Welcome to XHacker, your number one source for all things [product]. We're dedicated to giving you the very best of Hacking Course, with a focus on Ethical Hacking,Black Hat Hacking, and many morre.
Founded in 2016 by Ranjit Das, XHacker has come a long way from its beginnings in India. When RanjitDas first started out, His passion for Providing quality service them so that XHacker can offer you the most realiable service. We now serve customers all over the worls, and are thrilled that we're able to turn our passion into our own website.
We hope you enjoy our products as much as we enjoy offering them to you. If you have any questions or comments, please don't hesitate to contact us .
Sincerely, XHAcker Team
We are working with our heart to fulfill the customer needs and requirements.we hope you will also support us..
We donot focus on business,we focus on reliable service which makes the customer happy..
We have another great service that our Team will fully support you in any problem.We feel free to help you. Donot hesitste to inform your problem...


Tutorial¶
First step¶
setup simulation by
engine = Engine(Producer(), Consumer())
engine.run(range(20))
then run loop starts by
producer/initialize()
setup workers (by default by the number of cpu’s) on each worker start loop by
producer/consumer.initialize_worker()
and invoke loop over paths and start again with
producer/consumer.initialize_path()
then do time evolution of a path
producer.evolve() / consumer.consume()
and finish with last consumer in consumer stack
consumer[-1].finalize_path()
and
consumer[-1].finalize_worker()
put results into queue and take them out by
consumer[-1].put()/get(result)
finish simulation (kind of reduce method)
consumer[-1].finalize()
before returning results from run.


If you have take this quiz and learn what Language might be the best for you! It doesnt really matter what you pick to start with, but finding one that fits your needs will make it more fun and enjoyable.
Ive persobaly had a lot of fun learning JavaScript and JQuery and I'm looking forward to trying out Swift for iOS app developemnt when I'm done at Epicodus.


$$\ $$$$$$$\ $$$$$$$$\ $$$$$$\ $$$$$$$$\ $$$$$$\ $$$$$$$\ $$\ $$\ $$ | $$ __$$\ \__$$ __|$$ __$$\ $$ _____|$$ __$$\ $$ __$$\ $$$\ $$$ | $$$$$$\ $$ | $$ | $$ | $$ / \__| $$ | $$ / $$ |$$ | $$ |$$$$\ $$$$ | \_$$ _| $$$$$$$\ | $$ | $$ | $$$$$\ $$$$$$$$ |$$$$$$$ |$$\$$\$$ $$ | $$ | $$ __$$\ $$ | $$ | $$ __| $$ __$$ |$$ __$$< $$ \$$$ $$ | $$ |$$\ $$ | $$ | $$ | $$ | $$\ $$ | $$ | $$ |$$ | $$ |$$ |\$ /$$ | \$$$$ |$$$$$$$ | $$ | \$$$$$$ | $$ | $$ | $$ |$$ | $$ |$$ | \_/ $$ | \____/ \_______/ \__| \______/ \__| \__| \__|\__| \__|\__| \__|
---Pool Provider--- --------LP-------- --Reward Tokens-- --INFO-- Curve Curve tBTC CRV KEEP rewards discontinued Sushiswap Sushi WBTC-TBTC SUSHI rewards discontinued Sushiswap Sushi WETH-TBTC SUSHI rewards discontinued Uniswap ETH-TBTC KEEP 25k KEEP rewards per week Uniswap ETH-KEEP KEEP 170k KEEP rewards per week Uniswap KEEP-TBTC KEEP 100k KEEP rewards per week Saddle TBTC pool KEEP 250k KEEP rewards per week
Contacts: Crypto Investor #3523 on Keep Discord Github - github repo for this page External Links: Github - keep network github repo Twitter - official keep network twitter Medium - More detailed updates than twitter. Discord - A place to chat about tBTC farming. Special Thanks: yieldfarming.info - Thanks for the fork.


Methods, strategies, and tools for implementing software systems, particularly as part of a development team. Topics include the software development life cycle, Unified Modeling Language, software testing techniques, software security, open-source development, requirements gathering and documentation, maintenance, and basic software project management.
Prerequisites: CPSC-24500 Object-Oriented Programming
1. compare and contrast various software process models
2.be able to elicit and analyze requirements of a proposed application
3. write clear and complete requirements documents
4.identify the events to which the software must respond and document them as a set of use cases
5. identify security issues in a software projects requirements and design
6.use techniques to produce self-documenting code
7.use coding strategy to produce secure code
8.draw diagrams to model workflows
9.develop and use diagrams to model classes and the interaction of classes
10.understand and practice unit testing and functional testing
11.understand the techniques used to test non-functional requirements such as performance and security
12. develop a project schedule
1.develop programs using languages having different programming paradigms and for a variety of platforms
2. select the most appropriate data structures and algorithms for the given problem
3. explain how programming languages are designed and implemented
Lewis University, guided by its Catholic and Lasallian heritage, provides to a diverse student population programs for a liberal and professional education grounded in the interaction of knowledge and fidelity in the search for truth. Lewis promotes the development of the complete person through the pursuit of wisdom and justice. Fundamental to its Mission is a spirit of association, which fosters community in all teaching, learning and service. How this course connects to the University Mission: This course will allow us to extend our knowledge in software development, provide us the foundation for lifelong learning in this domain, and provide us the opportunity to assist each other on our learning journey
Textbook:Fox and Patterson. Engineering Software as a Service: An Agile Approach Using Cloud Computing. ISBN:<PHONE_NUMBER>246
E-Learning Headphone with Microphone: Our blended classroom setting requires a wired computer headset with a microphone for both in person and online participation.
Supplemental readings, videos, online materials: Additional readings, videos, and online materials will be provided.
Hardware and software requirements: This course requires access to multiple software tools. There are generally available for free but will need to be installed and utilized from a Windows or Macintosh computer.
Other required materials or costs: During this course we will be setting up and utilizing GitHub and Microsoft Azure accounts. We will be able to complete course assignments utilizing these resources for free or at a very low cost (estimated less than $20). A credit card will be needed to sign up for these accounts.
Understanding that the COVID-19 pandemic could influence the course of this semester, Lewis University will be guided by our Lasallian mission and the well- being of our community of students, faculty, and staff in respond and adapting to any sudden changes or circumstances. Based on the guidance of the State of Illinois and the Centers for Disease Control, it may be necessary to change the planned modality this course.
Because we are committed to student success, the University community is committed to academic standards while maintaining flexibility and empathy. Absences relating to the Coronavirus crisis will be recognized as excused. Students experiencing disruptions in their lives related to the Coronavirus that impact class attendance and participation should contact their instructor and/or college Dean’s Office for assistance. Students directly impacted by Coronavirus will have the ability to request alternative grading this semester. Requests will be evaluated on a case by case basis and will require documentation


Manage Images
All Images
Dockerfiles
Repo Images
{{ i.repoName }} labs
{{ li.nameLab }}
Download All Images
{{ p.name }}
Build image
Download image
Delete image
Installed Docker Images
Name Image:
Download
{{ ele.name }}
Delete
Dockerfiles
Create
{{t}}
From GitHub:
From
.dockerfile
:
{{d}}
{{d}}


Bandelier Marathon
White Rock NM/USA
Website: www.highaltitudeathletics.org/bandy.htm
Race Winners
(22 runnings)
18 May
2004
7:58:51
9:52:34
10 May
2003
8:11:55
9:19:08
11 May
2002
8:38:40
9:16:31
12 May
2001
7:12:05
7:16:12
21 Oct
2000
9:30:20
9:50:43
08 May
1999
7:55:23
8:54:44
09 May
1998
8:42:36
10:43:23
10 May
1997
6:52:27
12:26:41
11 May
1996
8:29:42
---
29 Apr
1995
7:08:18
13:06:26
30 Apr
1994
6:52:06
---
15 May
1993
6:59:14
---
02 May
1992
7:07:00
7:18:21
25 May
1991
6:58:08
---
26 May
1990
7:01:11
10:29:14
29 May
1989
6:23:03
7:41:14
30 May
1988
6:21:12
8:54:03
25 May
1987
7:07:34
10:14:44
26 May
1986
7:15:07
---
May
1985
6:27:06
---
28 May
1984
6:16:31
9:08:27
1983
6:12:42
7:41:36
Notes: 1983 was the inaugural year. In 1996, the race was postponed one week because of the Dome wildfire; in 2000,
the race was delayed five months because of the Cerro Grange wildfire. The start and finish for all years has been
the Nazarene Church in White Rock. The course was first certified in 1991.
Larry Cawthon-2
Lisa Valaika-3
Larry Cawthon (NM/USA)
Lisa Valaika-2
Bobby Keogh (NM/USA)
Andrea Foster (NM/USA)
Eric Clifton (NM/USA)
Emily Loman-2
Vince Anderson (NM/USA)
Lisa Valaika (NM/USA)
Randy Isler-2
Emily Loman (CO/USA)
Robert Reedy (NM/USA)
Susan Gardner (NM/USA)
Gary Wall (NM/USA)
Dianna Keogh-2
Earl Ortiz (NM/USA)
none
Kirk Apt (CO/USA)
Dianna Keogh (NM/USA)
Rodney Scharberg-2
none
Rodney Scharberg (NM/USA)
none
John Cappis (NM/USA)
Theresa Daus-Weber (CO/USA)
Ernst Baer-2
none
Ernst Baer (CO/USA)
Debbie Deupree (OK/USA)
Jerry Martinez-3
Julie Ann Wyns (CO/USA)
Steve Warshawer-3
Judy Milkie
Randy Isler (NM/USA)
Melda Dean
John Cappis (NM/USA)
none
Jerry Martinez-2
none
Jerry Martinez (NM/USA) & Steve Warshawer-2
Jan Fell (USA)
Steve Warshawer (NM/USA)
Jackie MacFarlane (NM/USA)
Most Wins
(1983-date)
Men
3
Steve Warshawer (NM/USA)
1983-84,1988
.
Jerry Martinez (NM/USA)
1984-85,1989
Women
3
Lisa Valaika (NM/USA)
2000,2003-04
Prize Money
(ADR qualified runners)
No prize money has been awarded at this race.
Race Time Bias
(sec/km)
The race time bias is not calculated for distances beyond 45 km..
Competitive Level
(1990-date)
Insufficient data to calculate the competitive level.
Quality Performances
Men No men under 5:06 Women No women under 6:10
Last Updated on 26 Jun 2005
Contributors: Rene LeClaire, Klaas Loonstra (5)


404: Page Not Found
Return to homepage
Send an email to
<EMAIL_ADDRESS>to alert to designer of the issue
Bad code by Jarrod Tyzack


RFLAT-1: a new zinc finger transcription factor that activates RANTES gene expression in T lymphocytes.
Abstract
RANTES (Regulated upon Activation, Normal T cell Expressed and Secreted) is a chemoattractant cytokine (chemokine) important in the generation of inflammatory infiltrate and human immunodeficiency virus entry into immune cells. RANTES is expressed late (3-5 days) after activation in T lymphocytes. Using expression cloning, we identified the first `` late '' T lymphocyte associated transcription factor and named it `` RANTES Factor of Late Activated T Lymphocytes-1 `` (RFLAT-1). RFLAT-1 is a novel, phosphorylated, zinc finger transcription factor that is expressed in T cells 3 days after activation, coincident with RANTES expression. While Rel proteins play the dominant role in RANTES gene expression in fibroblasts, RFLAT-1 is a strong transactivator for RANTES in T cells.


[gecode-users] (no subject)
Malcolm Ryan
malcolmr at cse.unsw.edu.au
Sun Feb 10 09:48:56 CET 2008
I may have asked this before. If I have, please forgive me for asking
again.
Suppose I have variables X1 ... Xn and Y1 ... Yn, with the constraints
distinct(X1, ..., Xn)
distinct(Y1, ..., Yn)
I now want to add the constraint:
Yi notin {Xj | j != i}, for i = 1 ... n
What would be the most efficient way to do this?
I could, of course, express it as:
Yi != X0
Yi != X1
...
Yi != Xi-1
Yi != Xi+ 1
...
Yi != Xn
The downside of this is that it would introduce a bunch of boolean
variables to keep track of.
Alternatively. I could say:
distinct(X1, .., Xi-1, Yi, Xi+1, ... Xn)
which is overkill, but doesn't add any extra constraints that are not
already covered by the original distinct(X1, ..., Xn) constraint.
Any suggestions as to which is likely to be better? Or is there
another way?
Malcolm
--
"Cleanliness is not next to godliness nowadays,
for cleanliness is made an essential
and godliness is regarded as an offence.
- G.K.Chesterton, On Lying in Bed
More information about the gecode-users
mailing list


BioinfoHub
Introduction and Motivation
1
Visualization
1.1
Volcano plot
1.2
Barplot
1.3
Boxplot
1.4
Scatter plot
1.5
Venn Diagram
1.6
UpSet plot
1.7
Heatmap
1.8
Bubble plot
1.9
Radar plot
2
Gene Expression Omnibus (GEO)
3
Differential Expression Analysis
4
Pathway Enrichment Anlaysis
5
Single-cell Sequencing
6
Databases
6.1
TCGA
6.2
GTEx
6.3
CCLE
6.4
Blueprint
6.5
Encode
6.6
Uniprot
6.7
Human Protein Atlas
References
Published with bookdown
BioinfoHub
Chapter 3
Differential Expression Analysis
Differential expression analysis


| ID | Property | Block | Street Name | Postal Code | Created At | Action |
|---|---|---|---|---|---|---|
|
1 |
Victoria Street |
134 |
The Towers |
221423 |
ddmmyyyy hh:mm |
|
|
2 |
Upper East Coast |
134 |
The Towers |
221423 |
ddmmyyyy hh:mm |
| ID | Created On | Filename | By | User ID | Action |
|---|---|---|---|---|---|
|
1 |
01-Feb-19 |
sitelayout.pdf | Nicole Eng | 21 |
| ID | Description | Filename | Created By | User ID | Created On | Action |
|---|---|---|---|---|---|---|
|
1 |
Brochure |
Filename.jpg |
Nicole Eng |
21 |
ddmmyy hh:mm |
| ID | Blk | Unit | FA (SM) | FA (SF) | LA (SM) | LA (SF) | Property Classification | Occupancy | Lease Commencement | Lease Expiry | Floor Plan | Action |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1 |
700 |
#01-11 |
106.00 |
1141 |
Residential |
Occupied |
ddmmyy |
Floor Plan Dummy.pdf |


BSc Biotechnology is a 3-year undergraduate course offered by a large number of public and private institutes in India. This course implements a combination of Biology with Technology and Computers. Candidates of this course are equipped with a plethora of knowledge in the field of Biology, Genetics, Molecular Structure and Computer Software. This course involves an advanced study of the cellular and biomolecular processes for the development of a variety of technologies and products contributing towards the improvement of people’s lives and health. The interested candidates need to qualify the 10+2 level from any recognized board of education with Physics, Chemistry and Biology as compulsory subjects. Admission to the BSc Biotechnology course is strictly done on the basis of the candidate’s marks obtained at the higher secondary level. However, some top colleges in India conducted their own entrance tests for getting admission to this course. After that, the qualifying candidates need to undergo a personal interview session for final selection. Some of the Top Colleges offering BSc Biotechnology program in India are : NIRF Overall Rank 2020- Name of the College/ University- Admission Process -Average Annual Fees - Average Annual Salary, 16 -JMI, New Delhi JMI Entrance Exam- INR 8,000 -INR 5,00,000, 42 -Fergusson College, Pune -Merit-Based -INR 11,025 -INR 4,25,000, 54 -JSS Academy of Higher Education and Research, Mysore -Merit-Based -INR 39,340 -INR 5,75,000, 59 -St. Xavier’s College, Ahmedabad -Entrance-Based -INR 60,185 -INR 4,00,000, 79 -Banasthali Vidyapith, Jaipur -Merit-cum-Aptitude Test- INR 1,17,500 -INR 6,25,000, The tuition fees for enrolling in BSc Biotechnology programs usually vary as per universities. The average annual course fees generally vary between INR 50,000 and 1,50,000.
BSc Biotechnology degree holders can get jobs in various profiles such as Lecturer, Research Associate, Research Scientist, Biotech Product Analyst, Marketing Manager etc. with an average annual salary ranging between INR 3,00,000 and 8,00,000. After completing this course, students can pursue higher studies and advanced academic exploration along with research through MSc and Certificate Courses. This course essentially provides a solid basis for further studies and related prospects.
What is the Admission Process for BSc BioTechnology?
The BSc Biotechnology Admission Process can vary as per the university rules and regulations. Some universities grant admission to students in BSc Biotechnology program based on merit. Some of the top-most Indian universities prefer conducting entrance exams to grant admission to qualified candidates. The admission procedures followed in the Indian universities for admission to BSc Biotechnology are given below. Admission Process Merit-based admission In merit-based admission, the universities offering BSc Biotechnology program grant admission to students based on their marks obtained in the Class 12 exams. Entrance-Based Admission The steps of the entrance-based admission are provided below: Registration: Students have to register for the entrance test by providing their email address, mobile number and password after which a login id will be created. Filling up of application form: On creation of login id, candidates are required to enter the required information correctly. Uploading of documents: In this step, candidates have to upload the necessary documents such as photograph, signature, id proof, Class 10 and 12 certificates, Bachelor’s degree etc. Application Fee: On uploading the requisite documents, students have to pay the requisite amount of application fee online. Issuing of Admit Card: Based on the details submitted by the students, the admission authority will issue the admit cards to the eligible students. Entrance Examination: After getting the admit card, exam dates will be released by different conducting bodies. Candidates have to sit for the entrance test and qualify the same to get admission. Declaration of Result: In the final stage, admission authorities will release the results of the entrance test they have appeared for. Enrolment: Successful candidates will then be allotted seats to the respective institutes.
What is the Eligibility Criteria for Admission to BSc Biotechnology course? The minimum eligibility criteria for students who want to pursue an BSc Biotechnology program from Indian universities are given below: Aspirants seeking admission to B.Sc Biotechnology are required to have passed Xth and XIIth with Physics, Biology, and Chemistry as core subjects, with min 50% overall (45% for SC/ST candidates), and 60% in each core subject. Both PCM & PCB candidates are eligible to apply. The Entrance is usually on a University or College level. Is There Any Entrance Exam for Admission to BSc Biotechnology course? A large number of Indian universities conduct entrance exams for BSc Biotechnology admissions. The entrance exams conducted thus vary according to the respective universities. Some of the most sought-after entrance examinations are:
How to prepare for BSc Biotechnology entrance exams?
Candidates are advised to follow the below mentioned points to score well in the entrance examination: The most popular B.Sc Biotechnology entrance exam is the Delhi University Entrance Test (DUET). It is used to grant admission to the courses offered by Delhi University, including B.Sc Biotechnology. It is conducted in English medium only and is for a duration of 2 hours. It is an Objective Type exam with 100 questions, with 400 marks in total. There is negative marking, -1 mark for each wrong answer. 4 marks are awarded for each correct answer. Visit the colleges’ websites and go through the eligibility and admission process. Make sure that you have applied in your preferable BSc Biotechnology college before the deadline. The admission to the BSc Biotechnology at top colleges is usually based on the entrance exams, so it is necessary to clear it up. Be prepared for the exam. Stay updated with the latest news regarding the colleges you have applied for.


de.polygonal.ds.TreeNode
- type
- class
- implements
- Collection<T>
Instance Methods
- parameters
process
Alternative to visit() if elements don't implement Visitable.
iterative
Uses an iterative postorder implementation.
userData
Optional user data that is passed to every visited node.
- parameters
process
Alternative to visit() if elements don't implement Visitable.
iterative
Uses an iterative preorder implementation.
userData
Optional user data that is passed to every visited node.
- returns
- The output array or a new array if output was not specified.
- returns
- The output vector or a new vector if output was not specified.


I was prescribed Gabapentin in mid of last year to help with my panic attacks. At the time I was only prescribed 50 mg, as needed. I fell off of that for a while, but I asked to be put back on a couple months back, but at a higher dosage, which started at 100 mg 2 times a day and since then me and my doctor have felt I needed to be put higher and higher until finally it's stopped at around 2400 mg, to 3200 mg, a day (that being around the highest you can ever be prescribed this stuff.)
My prescription is only supposed to be 800 mgs every 8 hours or so, but I've found that 1600 mgs is much nicer, if not even 2400 mg. Other people have said that taking this pharm. with a soda helps make it kick in faster, but taking it with a 16 ounce energy drink really makes it fast and hard.
Brings about the most euphoric feeling I have ever had. Life is perfect.  I have severe agoraphobia, and also slight paranoia, and while I am on this, it's completely gone. I love going out into the open, I love singing as I do, and all my surroundings are perfect. I love to look at everything and listen to everything.
One caution though, driving while on these is scary, although not. In retrospect it's scary because I am so in love with everything around me that I don't quite pay enough attention driving, but at the time, I feel perfect with my driving, in fact it's everyone elses driving that is horrible.
I've been giving this drug to my friends that have anxiety problems and it's been a complete godsend for them as well as me. It is perfect. It's better than marijuana, it's better than alcohol, it's better than any narcotic, but it is perfect to have with ultram, or tramadol. I take 150 mg of tramadol, and 1600 mg of gabapentin, and I'm floating for the rest of the day.
A few of my friends have had little to no effects of taking this. This is because they have little to no anxiety or stress in their lives. I try to only give it to my friends that I know need it. It helps me think more clearly and deal with anything that life throws my way. I feel like I could lose everything in my life and be content with life still while I'm on it.
I still need to try this with alcohol or xanax, as both of those affect your gaba receptors, as does gabapentin obviously, because they will increase the euphoric feeling, but i feel fine without them. Gabapentin has saved my life, and I know it. It is the perfect drug. All my friends on it agree that it is better than any pain killer out there, along with any other drug out there. It has caused slight hallucinations with me, but nothing really.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


SpaceX Prototype Blows Its Top During Pressure Tests | Breitbart
Elon Musk’s SpaceX Starship rocket suffered another setback this week after it partially burst apart during pressure testing in Texas.
by Lucas NolanThe Verge reports that Elon Musk’s space exploration firm SpaceX saw another setback when its Starship rocket partially burst apart during a recent ground test in Texas. The rocket’s gas as sent pieces of hardware flying into the sky as livestreams set up by local space enthusiasts captured the entire incident.
A video of the incident can be seen below:
A SpaceX spokesperson told The Verge in a comment that the rocket bursting apart was not a serious setback stating: “The purpose of today’s test was to pressurize systems to the max, so the outcome was not completely unexpected. There were no injuries, nor is this a serious setback.”
The latest test was focusing on testing the design of the starship which SpaceX hopes will be capable of transporting cargo and people to deep space destinations such as Mars and the Moon. Musk indicated in September that the test vehicle could be doing flights to low altitudes within months and a version of the Starship would be capable fo reaching Earth orbit within six months.
But after the latest explosion, Musk indicated on twitter that SpaceX may no longer fly this particular prototype of the Starship and will be conducting flight tests with newer models that the firm plans to build. Referring to the latest failed prototype, Musk stated: “This had some value as a manufacturing pathfinder, but flight design is quite different.”
In July of 2019, SpaceX’s Starhopper small-scale test spacecraft exploded into flames after what appeared to be a fuel leak or fuel dump during a static fire test at SpaceX’s facility in Boca Chica, Texas. The Starhopper is a smaller-scale version of a larger spacecraft the firm is currently developing and is designed to test ideas for the larger version. It is expected that the Starhopper will be capable of performing short space flights called “hops.”
Lucas Nolan is a reporter for Breitbart News covering issues of free speech and online censorship. Follow him on Twitter @LucasNolan or email him at lnolan@breitbart.com