This part shows you how to build applications that perform secure communications. The Java SE 6 platform provides three standard APIs that allow applications to perform secure communications: The Java Generic Security Service (GSS), the Java SASL API, and the Java Secure Socket Extension (JSSE). When building an application, which of these APIs should you use? The answer depends on many factors, including requirements of the protocol or service, deployment infrastructure, and integration with other security services. For example, if you are building an LDAP client library, you would need to use the Java SASL API because use of SASL is part of LDAP's protocol definition. As an other example, if the service supports SSL, then the client application attempting to access the service would need to use JSSE.
Exercise 3: Using the Java Generic Security Service (GSS) API
Goal of this exercise:
The goal of this exercise is to learn how to use the Java GSS API to perform secure authentication and communication.
Background for this exercise:
The Generic Security Service API provides a uniform C-language interface to access various security services, such as authentication, message integrity, and message confidentiality. The Java GSS API provides the corresponding interface for Java applications. It allows applications to perform authentication and establish secure communication with the peer. One of the most common security service accessed via the GSS-API and Java GSS-API is Kerberos.
Resources for this Exercise:
- The JAAS and Java GSS-API Tutorials
- Generic Security Service API Version 2: Java Bindings (RFC 2853)
- Java GSS javadocs: org.ietf.jgss.
Overview of this Exercise:
This exercise is a client-server application that demonstrates how to communicate securely using the Java GSS API. The client and server parts first authenticate to Kerberos, as shown in Exercise 1. This stores the credentials in the subject. The application then executes an action that performs Java GSS operations (with Kerberos as the underlying GSS mechanism) inside of a Subject.doAs using the subject. The Java GSS Kerberos mechanism, because it is executing inside the doAs, obtains the Kerberos credentials from the subject, and uses them to authenticate with the peer and to exchange messages securely.
Steps to follow:
- Read the following code. This is located in
src/GssServer.java.
This code fragment defines the action to execute after the service principal has authenticated to the KDC. It replaces the MyAction of line 11 of Exercise 1. Note the highlighted lines. The code first creates an instance of GSSManager
[line 8], which it uses to obtain its own credentials [line 10-11] and to create an instance of GSSContext
[line 18]. It uses this context to perform authentication [the loop between lines 22-34]. Upon completing authentication, it accepts encrypted input from the client and uses the established security context to decrypt the data [line 45]. It then uses the security context to encrypt a reply containing the original input and the date [line 49], and then sends it back to the client.
Code listing for GssServer.java
.
static class GssServerAction implements PrivilegedExceptionAction {
...
public Object run() throws Exception {
// Create server socket for accepting connections
ServerSocket ss = new ServerSocket(localPort);
// Get own Kerberos credentials for accepting connection
GSSManager manager = GSSManager.getInstance();
Oid krb5Oid = new Oid("1.2.840.1135<IP_ADDRESS>");
GSSCredential serverCreds = manager.createCredential(null,
GSSCredential.DEFAULT_LIFETIME, krb5Oid, GSSCredential.ACCEPT_ONLY);
while (true) {
Socket socket = ss.accept();
DataInputStream inStream = new DataInputStream(socket.getInputStream());
DataOutputStream outStream = new DataOutputStream(socket.getOutputStream());
GSSContext context = manager.createContext((GSSCredential)serverCreds);
// Do the context establishment loop
byte[] token = null;
while (!context.isEstablished()) {
// Read token
token = new byte[inStream.readInt()];
inStream.readFully(token);
// Process token
token = context.acceptSecContext(token, 0, token.length);
// Send a token to the peer if one was generated by acceptSecContext
outStream.writeInt(token.length);
outStream.write(token);
outStream.flush();
}
// Context established!
// Create MessageProp for use with unwrap (will be set upon return from unwrap)
MessageProp prop = new MessageProp(0, false);
// Read token from client
token = new byte[inStream.readInt()];
inStream.readFully(token);
// Unwrap (decrypt) token sent by client
byte[] input = context.unwrap(token, 0, token.length, prop);
...
// Create new token and send to client
byte[] reply = ...;
token = context.wrap(reply, 0, reply.length, prop);
outStream.writeInt(token.length);
outStream.write(token);
outStream.flush();
context.dispose();
socket.close();
}
}
}
|
- Compile the sample code.
% javac GssServer.java
- Read the following code. This is located in
src/GssClient.java.
This code fragment defines the action to execute after the client principal has authenticated to the KDC. It replaces the MyAction of line 11 of Exercise 1. Note the highlighted lines. The code first creates an instance of GSSManager
[line 10], which it uses to obtain a principal name for the service that it is going to communicate with [line 12]. It then creates an instance of GSSContext
[line 15,16] to perform authentication [the loop between lines 22-33] with the service. Upon completing authentication, it uses the established security context to encrypt a message [line 42] and sends it to the server. It then reads an encrypted message from the server and decodes it using the established security context [line 53].
Code listing for GssClient.java
.
static class GssClientAction implements PrivilegedExceptionAction {
...
public Object run() throws Exception {
// Create socket to server
Socket socket = new Socket(hostName, port);
DataInputStream inStream = new DataInputStream(socket.getInputStream());
DataOutputStream outStream = new DataOutputStream(socket.getOutputStream());
// Get service's principal name
GSSManager manager = GSSManager.getInstance();
Oid krb5Oid = new Oid("1.2.840.1135<IP_ADDRESS>");
GSSName serverName = manager.createName(serverPrinc, GSSName.NT_HOSTBASED_SERVICE);
// Get the context for authentication
GSSContext context = manager.createContext(serverName, krb5Oid, null,
GSSContext.DEFAULT_LIFETIME);
context.requestMutualAuth(true); // Request mutual authentication
context.requestConf(true); // Request confidentiality
// Do the context establishment loop
byte[] token = new byte[0];
while (!context.isEstablished()) {
token = context.initSecContext(token, 0, token.length);
outStream.writeInt(token.length);
outStream.write(token);
outStream.flush();
// Check if we're done
if (!context.isEstablished()) {
token = new byte[inStream.readInt()];
inStream.readFully(token);
}
}
// Context established!
// Create MessageProp for use with unwrap (true means request confidentiality)
MessageProp prop = new MessageProp(0, true);
// Create encrypted message and send to server
byte[] reply = ...;
token = context.wrap(reply, 0, reply.length, prop);
outStream.writeInt(token.length);
outStream.write(token);
outStream.flush();
// Read token from server
token = new byte[inStream.readInt()];
inStream.readFully(token);
// Unwrap (decrypt) token sent by server
byte[] input = context.unwrap(token, 0, token.length, prop);
...
context.dispose();
socket.close();
return null;
}
}
|
- Compile the sample code.
% javac GssClient.java
- Launch a new window and start the server.
% xterm &
% java -Djava.security.auth.login.config=jaas-krb5.conf \
GssServer
- Run the client application. GssClient takes two parameters: the service name and the name of the server that the service is running on. For example, if the service is
host
running on the machine j1hol-001
, you would enter the following. When prompted for the password, enter changeit.
% java -Djava.security.auth.login.config=jaas-krb5.conf \
GssClient host j1hol-001
- Observe the following output in the client and server applications' windows.
Output for running GssServer example.
Authenticated principal<EMAIL_ADDRESS>Waiting for incoming connections...
Got connection from client /<IP_ADDRESS>
Context Established!
Client principal is<EMAIL_ADDRESS>Server principal is<EMAIL_ADDRESS>Mutual authentication took place!
Received data "Hello There!" of length 12
Confidentiality applied: true
Sending: Hello There! Thu May 06 12:11:15 PDT 2005
|
Output for running GssClient example.
Kerberos password for test: changeit
Authenticated principal<EMAIL_ADDRESS>Connected to address j1hol-001/<IP_ADDRESS>
Context Established!
Client principal is<EMAIL_ADDRESS>Server principal is host@j1hol-001
Mutual authentication took place!
Sending message: Hello There!
Will read token of size 93
Received message: Hello There! Thu May 06 12:11:15 PDT 2005
|
Summary:
In this exercise, you learned how to write a client-server application that uses the Java GSS API to authenticate and communicate securely with each other.
Next Steps
- Proceed to Exercise 4 to learn how to write a client/server application that uses the Java SASL API to authenticate and communicate securely with each other.
- Proceed to Exercise 5 to learn how to write a client/server application that uses the JSSE to authenticate and communicate securely with each other.
- Proceed to Exercise 6 to learn how to configure the sample programs that you have just used to achieve single sign-on in a Kerberos environment.
Exercise 4: Using the Java SASL API
Goal of this exercise:
The goal of this exercise is to learn how to use the Java SASL API to perform secure authentication and communication.
Background for this exercise:
Simple Authentication and Security Layer (SASL) specifies a challenge-response protocol in which data is exchanged between the client and the server for the purposes of authentication and (optional) establishment of a security layer on which to carry on subsequent communications. SASL allows different mechanisms to be used; each such mechanism is identified by a profile that defines the data to be exchanged and a name. SASL is used with connection-based protocols such as LDAPv3 and IMAPv4. SASL is described in RFC 4422.
The Java SASL API defines an API for applications to use SASL in a mechanism-independent way. For example, if you are writing a library for a networking protocol that uses SASL, you can use the Java SASL API to generate the data to be exchanged with the peer. When the library is deployed, you can dynamically configure the mechanisms to use with the library.
In addition to authentication, you can use SASL to negotiate a security layer to be used after authentication. But unlike the GSS-API, the properties of the security layer (such as whether you want integrity or confidentiality) is decided at negotiation time. (the GSS-API allows confidentiality to be turned on or off per message).
Resources for this exercise:
- The Java SASL API Programming and Deployment Guide
- The Java SASL API javadocs
- Simple Authentication and Security Layer (SASL) (RFC 4422)
Overview of this exercise:
This exercise is a client-server application that demonstrates how to communicate securely using the Java SASL API. The client and server parts first authenticate to Kerberos using Exercise 1. This stores the credentials in the subject. The application then executes an action that performs Java SASL API operations (with Kerberos as the underlying SASL mechanism) inside of a Subject.doAs using the subject. The SASL/Kerberos mechanism, because it is executing inside the doAs, obtains the Kerberos credentials from the subject, and uses them to authenticate with the peer and to exchange messages securely.
This example uses a simple protocol implemented by the AppConnection
class. This protocol exchanges authentication commands and data commands. Each command consists of a type (e.g., AppConnection.AUTH_CMD), the length of the data to follow, and the data itself. The data is a SASL buffer if it is for authentication or encrypted/integrity-protected application data; it is plain application data otherwise.
Steps to follow:
- Read the following code. This is located in
src/SaslTestServer.java.
This code fragment defines the action to execute after the service principal has authenticated to the KDC. It replaces the MyAction of line 11 of Exercise 1. Note the highlighted lines. The server specifies the quality-of-protections that it will support [line 9] and then creates an instance of SaslServer to perform the authentication [line 21]. The challenge-response protocol of SASL is performed in the while loop [lines 33-49], with the server sending challenges to the client and processing the responses from the client. After authentication, the identity of the authenticated client can be obtained via a call to getAuthorizedID() [line 61]. If a security layer was negotiated, the server can exchange data securely with the client [lines 66,70].
Code listing for SaslTestServer.java
.
static class SaslServerAction implements PrivilegedExceptionAction {
...
public Object run() throws Exception {
// Create server socket for accepting connections
ServerSocket ss = new ServerSocket(localPort);
// Support all quality-of-protection options
HashMap<String,Object> props = new HashMap<String,Object>();
props.put(Sasl.QOP, "auth-conf,auth-int,auth");
while (true) {
// Create application-level connection to handle request
Socket socket = ss.accept();
AppConnection conn = new AppConnection(socket);
// Normally, the application protocol will negotiate which
// SASL mechanism to use. In this simplified example, we
// will always use "GSSAPI" (the name of the mechanism that does Kerberos via GSS-API)
// Create SaslServer to perform authentication
SaslServer srv = Sasl.createSaslServer("GSSAPI", service, serviceName, props, cbh);
if (srv == null) {
// ... handle error
}
// Read the initial response from client
byte[] response = conn.receive(AppConnection.AUTH_CMD);
AppConnection.AppReply clientMsg;
boolean auth = false;
// Perform authentication
while (!srv.isComplete()) {
try
// Generate challenge based on response
byte[] challenge = srv.evaluateResponse(response);
if (srv.isComplete()) {
conn.send(AppConnection.SUCCESS, challenge);
auth = true;
} else {
clientMsg = conn.send(AppConnection.AUTH_IN_PROGRESS, challenge);
response = clientMsg.getBytes();
}
} catch (SaslException e) {
// Send failure notification to client
conn.send(AppConnection.FAILURE, null);
break;
}
}
// Authentication completed!
// Check status of authentication
if (srv.isCompleted() && auth) {
System.out.println("authorized client is: " + srv.getAuthorizationID());
} else {
// Report failure ...
}
// Find out whether security layer was negotiated
String qop = (String) srv.getNegotiatedProperty(Sasl.QOP);
boolean sl = (qop.equals("auth-conf") || qop.equals("auth-int"));
// Read and decrypt message from client
byte[] msg = conn.receive(AppConnection.DATA_CMD);
byte[] realMsg = (sl ? srv.unwrap(msg, 0, msg.length) : msg);
...
// Create and encrypt message to send to client
byte[] reply = ...;
byte[] realReply = (sl ? srv.wrap(reply, 0, reply.length) : reply);
conn.send(AppConnection.SUCCESS, realReply);
}
}
}
|
- Compile the sample code.
% javac SaslTestServer.java
- Read the following code. This is located in
src/SaslTestClient.java.
This code fragment defines the action to execute after the client principal has authenticated to the KDC. It replaces the MyAction of line 11 of Exercise 1. Note the highlighted lines. The program first specifies the quality of protection that it wants (in this case, confidentiality) [line 8] and then creates an instance of SaslClient to use for authentication [lines 11-12]. It then checks whether the mechanism has an initial response and if so, gets the response by invoking evaluateChallenge() with an empty byte array [line 20]. It then sends the response to the server to begin the authentication. The challenge-response protocol of SASL is performed in the while loop [lines 24-39], with the client evaluating the challenges that it gets from the server and sending the server the corresponding
responses to the challenges. After authentication, the client can proceed to communicate with the server using the negotiated security layer [lines 48,55].
Code listing for SaslTestClient.java
.
static class SaslClientAction implements PrivilegedExceptionAction {
...
public Object run() throws Exception {
// Create application-level connection
AppConnection conn = new AppConnection(serverName, port);
HashMap<String,Object> props = new HashMap<String,Object>();
props.put(Sasl.QOP, "auth-conf"); // Request confidentiality
// Create SaslClient to perform authentication
SaslClient clnt = Sasl.createSaslClient(
new String[]{"GSSAPI"}, null, service, serverName, props, cbh);
if (clnt == null) {
// ... handle error
}
byte[] challenge;
// Get initial response for authentication
byte[] response = clnt.hasInitialResponse() ? clnt.evaluateChallenge(EMPTY) : EMPTY;
AppConnection.AppReply reply = conn.send(AppConnection.AUTH_CMD, response);
// Repeat until authentication terminates
while (!clnt.isComplete() &&
(reply.getStatus() == AppConnection.AUTH_INPROGRESS ||
reply.getStatus() == AppConnection.SUCCESS))
// Evaluate challenge to generate response
challenge = reply.getBytes()
response = clnt.evaluateChallenge(challenge)
if (reply.getStatus() == AppConnection.SUCCESS) {
if (response != null) {
throw new Exception("Protocol error")
}
break;
}
// Send response to server and read server's next challenge
reply = conn.send(AppConnection.AUTH_CMD, response);
}
// Authentication completed!
// Find out whether security layer was negotiated
String qop = (String) srv.getNegotiatedProperty(Sasl.QOP);
boolean sl = (qop.equals("auth-conf") || qop.equals("auth-int"));
byte[] msg = ...;
// Create and send encrypted data to server
byte[] encrypted = (sl ? clnt.wrap(msg, 0, msg.length) : msg);
reply = conn.send(AppConnection.DATA_CMD, encrypted);) {
...
// Read and decrypt data from server
byte[] encryptedReply = reply.getBytes();
byte[] clearReply = (sl ? clnt.unwrap(encryptedReply, 0, encryptedReply.length)
: encryptedReply);
conn.close();
return null;
}
}
|
- Compile the sample code.
% javac SaslTestClient.java
- Launch a new window and start the server. SaslTestServer takes two parameters: the service name and the name of the server that the service is running on. For example, if the service is
host
running on the machine j1hol-001
, you would enter the following.
% xterm &
% java
-Djava.security.auth.login.config=jaas-krb5.conf \
SaslTestServer host j1hol-001
- Run the client application. SaslTestClient takes two parameters: the service name and the name of the server that the service is running on. For example, if the service is
host
running on the machine j1hol-001
, you would enter the following. When prompted for the password, enter changeit.
% java -Djava.security.auth.login.config=jaas-krb5.conf \
SaslTestClient host j1hol-001
- Observe the following output in the client and server applications' windows.
Output for running the SaslTestServer
example.
Authenticated principal<EMAIL_ADDRESS>Waiting for incoming connections...
Got connection from client /<IP_ADDRESS>
Client authenticated; authorized client is<EMAIL_ADDRESS>Negotiated QOP: auth-conf
Received: Hello There!
Sending: Hello There! Fri May 07 15:32:37 PDT 2005
Received data "Hello There!" of length 12
|
Output for running the SaslTestClient
example.
Kerberos password for test: changeit
Authenticated principal<EMAIL_ADDRESS>Connected to address j1hol-001/<IP_ADDRESS>
Client authenticated.
Negotiated QOP: auth-conf
Sending: Hello There!
Received: Hello There! Fri May 07 15:32:37 PDT 2005
|
- To try the program using different quality-of-protection, change line 8 in
SaslTestClient
. For example, replace line 8 with the following line to use integrity protection on (no confidentiality).
props.put(Sasl.QOP, "auth-int");
Summary:
In this exercise, you learned how to write a client-server application that uses the Java SASL API to authenticate and communicate securely with each other.
Next Steps
- Proceed to Exercise 5 to learn how to write a client/server application that uses the JSSE to authenticate and communicate securely with each other.
- Proceed to Exercise 6 to learn how to configure the sample programs that you have just used to achieve single sign-on in a Kerberos environment.
Exercise 5: Using the Java Secure Socket Extension with Kerberos
Goal of this exercise:
The goal of this exercise is to learn how to use the JSSE API to perform secure authentication and communication using Kerberos cipher suites.
Background for this exercise:
Secure Socket Layer (SSL) and Transport Layer Security (TLS) are the most widely used protocols for implementing cryptography on the Internet. TLS is the Internet standard evolved from SSL. SSL/TLS provides application-level protocols (such as HTTP and LDAP) with secure authentication and communication. For example, HTTPS is the resulting protocol of using HTTP over SSL/TLS. SSL/TLS is used not only for standard protocols such as HTTP, it is also widely used when building custom applications using custom protocols that need to communicate securely.
SSL/TLS traditionally used certificate-based authentication and is commonly used for server-authentication. For example, when a Web client such as a browser accesses a secure Web site (server) on behalf of a user, the server sends its certificate to the browser so that the browser can verify the identity of the server. This ensures that the user does not divulge confidential information (such as credit card information) to a bogus server. Recently, a new standard allows the use of Kerberos with TLS. This means instead of using certificate-based authentication, an application can use Kerberos credentials and take advantage of the Kerberos infrastructure in the deployment environment. Using Kerberos cipher suites also provides automatic support for mutual authentication in which the client is also authenticated in addition to the server.
The decision of whether to use Java GSS, Java SASL, or JSSE for a particular application often depends upon several factors, including (the protocols being used by) the services with which the application interacts, the deployment environment (PKI or Kerberos-based), and the application's security requirements. JSSE provides a secure end-to-end channel that takes care of the I/O and transport, while Java GSS and Java SASL provide encryption and integrity-protection on the data, but the application is responsible for transporting the secured data to its peer. Some details about factors for deciding when to use JSSE versus Java GSS are presented in the document, When to use Java GSS vs. JSSE.
Resources for this exercise:
- Java Secure Socket Extension (JSSE) Reference Guide
- The JSSE javadocs: javax.net and javax.net.ssl
- The SSL Protocol version 3.0
- The TLS Protocol Version 1.0 (RFC 2246)
- Addition of Kerberos Cipher Suites to Transport Layer Security TLS (RFC 2712)
- When to use Java GSS vs. JSSE
Overview of this exercise:
This exercise is a client-server application that demonstrates how to communicate securely using the JSSE and Kerberos cipher suites. The client and server parts first authenticate to Kerberos using Exercise 1. This stores the credentials in the subject. The application then executes an action that performs JSSE operations (using a Kerberos cipher suite) inside of a Subject.doAs using the subject. The Kerberos cipher suite implementation, because it is executing inside the doAs, obtains the Kerberos credentials from the subject, and uses them to authenticate with the peer and to exchange messages securely. This example sends newline-terminated messages, encrypted using the negotiated cipher suite and integrity-protected, back and forth between client and server.
According to the standard (RFC 2712) all Kerberos-enabled TLS applications use the same service name, namely, "host". That is why in this exercise, you do not need to explicitly supply the Kerberos service name.
Steps to follow:
- Read the following code. This is located in
src/JsseServer.java
This code fragment defines the action to execute after the service principal has authenticated to the KDC. It replaces the MyAction of line 11 of Exercise 1. Note the highlighted lines. The server first creates an SSLServerSocket [lines 5-8]. This is analogous to an application creating a plain ServerSocket except an SSLServerSocket will provide automatic authentication, encryption and decryption, as needed. The server then sets the cipher suites that it wants to use [lines 11-12]. The server then runs in a loop, accepting connections from SSL clients [line 17], and reads and writes from the SSL socket [lines 23, 28]. The server can find out the identities of the owners of socket by invoking the getLocalPrincipal() and getPeerPrincipal() methods [lines 32-33].
Code listing for JsseServer.java
.
static class JsseServerAction implements PrivilegedExceptionAction {
...
public Object run() throws Exception {
// Create TLS socket for accepting connections
SSLServerSocketFactory sslssf =
(SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
SSLServerSocket sslServerSocket =
(SSLServerSocket) sslssf.createServerSocket(localPort);
// Enable only a Kerberos cipher suite
String enabledSuites[] = { "TLS_KRB5_WITH_3DES_EDE_CBC_SHA" };
sslServerSocket.setEnabledCipherSuites(enabledSuites);
// Should handle exception if enabledSuites is not supported
while (true) {
// Create socket to handle request
SSLSocket sslSocket = (SSLSocket) sslServerSocket.accept();
BufferedReader in = new BufferedReader(new InputStreamReader(
sslSocket.getInputStream()));
BufferedWriter out = new BufferedWriter(new OutputStreamWriter(
sslSocket.getOutputStream()));
String inStr = in.readLine();
// ... use inStr
// Compose and send reply
String outStr = inStr + " " + new Date().toString() + "\n";
out.write(outStr);
out.flush();
// Get names of principal at both ends of secure connection
Principal self = sslSocket.getSession().getLocalPrincipal();
Principal peer = sslSocket.getSession().getPeerPrincipal();
sslSocket.close();
}
}
}
|
- Compile the sample code.
% javac JsseServer.java
- Read the following code. This is located in
src/JsseClient.java
. This code fragment defines the action to execute after the client principal has authenticated to the KDC. It replaces the MyAction of line 11 of Exercise 1. Note the highlighted lines. The client first creates an SSLSocket. The client then sets the cipher suites that it wants to use [lines 11-12]. The client then exchanges messages with the server using the SSLSocket by reading and writing to the socket's input/output streams. The client can find out the identities of the owners of socket by invoking the getLocalPrincipal() and getPeerPrincipal() methods [lines 26-27].
Code listing for JsseClient.java
static class JsseClientAction implements PrivilegedExceptionAction {
...
public Object run() throws Exception {
// Create SSL connection
SSLSocketFactory sslsf = (SSLSocketFactory) SSLSocketFactory.getDefault();
SSLSocket sslSocket = (SSLSocket) sslsf.createSocket(server, port);
// Enable only a Kerberos cipher suite
String enabledSuites[] = { "TLS_KRB5_WITH_3DES_EDE_CBC_SHA" };
sslSocket.setEnabledCipherSuites(enabledSuites);
// Should handle exception if enabledSuites is not supported
BufferedReader in = new BufferedReader(new InputStreamReader(
sslSocket.getInputStream()));
BufferedWriter out = new BufferedWriter(new OutputStreamWriter(
sslSocket.getOutputStream()));
String outStr = ...;
out.write(outStr);
out.flush();
String inStr = in.readLine();
// ... use inStr
// Get names of principal at both ends of secure connection
Principal self = sslSocket.getSession().getLocalPrincipal();
Principal peer = sslSocket.getSession().getPeerPrincipal();
sslSocket.close();
return null;
}
}
|
- Compile the sample code.
% javac JsseClient.java
- Launch a new window and start the server. JsseServer takes one parameter: the name of the server that the JSSE service is running on. For example, if it is running on the machine
j1hol-001
, you would enter the following.
% xterm &
% java
-Djava.security.auth.login.config=jaas-krb5.conf \
JsseServer j1hol-001
- Run the client application. JsseClient takes one parameter: the name of the server that the JSSE service is running on. For example, if the service is running on the machine
j1hol-001
, you would enter the following. When prompted for a password, enter changeit.
% java -Djava.security.auth.login.config=jaas-krb5.conf \
JsseClient j1hol-001
- Observe the following output in the client and server applications' windows.
Output for running the JsseServer
example.
Authenticated principal<EMAIL_ADDRESS>Waiting for incoming connections...
Got connection from client /<IP_ADDRESS>
Received: Hello There!
Sending: Hello There! Fri May 07 15:32:37 PDT 2005
Cipher suite in use: TLS_KRB5_WITH_3DES_EDE_CBC_SHA
I am<EMAIL_ADDRESS>Client is<EMAIL_ADDRESS>|
Output for running the JsseClient
example.
Kerberos password for test: changeit
Authenticated principal<EMAIL_ADDRESS>Sending: Hello There!
Received: Hello There! Fri May 07 15:32:37 PDT 2005
Cipher suite in use: TLS_KRB5_WITH_3DES_EDE_CBC_SHA
I am<EMAIL_ADDRESS>Server is<EMAIL_ADDRESS>|
Summary:
In this exercise, you learned how to write a client-server application that uses JSSE to authenticate and communicate securely with each other, using Kerberos as the underlying authentication system.
Next Steps
- Proceed to Exercise 6 to learn how to configure the sample programs in Exercises 3, 4, and 5 to achieve single sign-on in a Kerberos environment.


WITNESS LIST
Finance
February 11, 2019 10:00 AM
FOR:
Bacak, Jennifer Real Estate Agent (Myself), College Station, TX
Bush, Pierce Big Brothers Big Sisters Lone Star (also providing written testimony) (My
organization and our state affiliates)
Pennington, Joel Student (Self)
Pennington, Orit small business owner (Self), Hou, TX
Pennington, Robert small business owner (Self), Hou, TX
Stasny, David Attorney (Texas Association of School Boards), College Station, TX
Williams, Doug Education (also providing written testimony) (Texas Association of
School Administrators), Sunnyvale
ON:
Aleman, Steven Policy Specialist (also providing written testimony) (Disability Rights
Texas)
Benestante, Jacquie Director of Advocacy & Outreach (also providing written testimony)
(Autism Society of TX), Austin, TX
Bugen, Claire Superintendent (also providing written testimony) (Texas School f/t Deaf)
Carpenter, Dr. Clint Superintendent (also providing written testimony) (Windham School
District), Huntsville, TX
Daugherty, William TSBVI (also providing written testimony) (TSBVI), Austin, TX
Exter, Monty Senior lobbyist (The Association of Texas Professional Educators), Austin,
TX
Fickel, Ann Assoc. Exec. Director (TX Classroom Teachers Association), Austin
Flores, Lisa advocacy specialist (also providing written testimony) (Easter Seals Texas &
affiliates)
Guthrie, Brian Executive Director (also providing written testimony) (TRS), Austin
Hawk, Austin teacher (also providing written testimony) (Self)
Henricksen, Aaron LBB Staff (also providing written testimony) (LBB)
Hernandez, Demetrio LBB Staff (also providing written testimony) (LBB)
Hoffman, Shannon Policy Fellow (also providing written testimony) (The Hogg
Foundation for Mental Health)
Holladay, Tedd LBB Staff (also providing written testimony) (LBB)
Howell, Cherie Dyslexia Coordinator (also providing written testimony) (Texas ALTA),
Frisco, TX
Knapp, Tammy Chief Financial Officer (also providing written testimony) (National Math
and Science Initiative), Dallas, TX
Lee, Tim Executive Director (also providing written testimony) (TX Retired Teachers
Assn), Austin, TX
Lopez, Leonardo Chief School Finance Officer (also providing written testimony) (Texas
Education Agency), Austin, TX
MacLaurin, Andy LBB Staff (also providing written testimony) (LBB)
McGeady, John LBB Staff (also providing written testimony) (LBB)
Morath, Mike Commissioner, TEA (also providing written testimony) (TEA), Austin, TX
Overmyer, Andrew LBB Staff (also providing written testimony) (LBB)
WITNESS LIST
Finance
February 11, 2019 10:00 AM
Piccola, Kyle Government Relations Officer (The Arc of Tx), ATX
Rome, Christy Executive Director (Texas School Coalition), Austin, TX
Saxe, Avery LBB Staff (also providing written testimony) (LBB)
Siedlecki, Joe Associate Commissioner (also providing written testimony) (TEA)
Smith, Orion teacher (also providing written testimony) (Self)
Spivey, Ray (also providing written testimony) (TRS), Austin
Sughrue, Alissa Policy Coordinator (also providing written testimony) (NAMI Texas)
Tucker, Chris Student (also providing written testimony) (Communities In Schools of
Texas), Selma, TX
Villanueva, Chandra Director, Economic Opportunity (Center for Public Policy Priorities),
Austin
Registering, but not testifying:
FOR:
Hutchison, Ryan nonprofit management (TSD Governing Board)
Saunders, David ower of Private Business (TSD Governing Board), Waxahachie, TX
ON:
Broughal, Christine Education Advocate (Texans for Special Education Reform), Cedar
Park, TX
Darden, Pamela CFO - TSBVI (Tx School for the Blind & Visually Impaired), Austin
Haughtling, Susan Director of Planning & Evaluations (Tx. School for the Blind &
Visually Impaired), Austin, TX
Litzinger, Amy (myself), Austin, TX
Loyola, LeAnn Budget Analyst (TSD), Austin, TX
Masey, Chris advocacy director (Coalition of Texans with Disabilities)
O'Banion, Robert Chief Financial Officer (Windham School District), Huntsville, TX
Pobedinsky, Maria Legislative Intern (Disability Rights Texas)
Raff, John Dep Exec Dir., TFC (TFC resource)
Smith, Kimberly CFO (Frisco ISD), Frisco, TX
Stie-Buckles, Michelle VP (National Math & Science Initiative), Dallas, TX
Wedel, Justin CFO (Texas School For The Deaf), Austin
Providing written testimony:
FOR:
Butler, Daaniel ResidentIal Instructor Ii (Self; Texas School for the Blind and Visually
Impaired), Austin, TX
Dawn-Fisher, Lisa Legislative Consultant (Texas State Teachers Association)
Ramirez, Valeria (Texas School for the Blind and Visually Impaired), Austin, TX
Thompson, Tyler Coordinator (Self), Austin, TX
AGAINST:
Cripps, Charles and Kristie Mr. and Mrs. (Self; 250,000 and our son denied disability
identification services under the 8.5% Cap.), Bryan,, TX
ON:
Bey, Sharon School Counseling (Texas School Counselor Association), Waller, TX
Clarke, Debby (Self), Austin, TX
WITNESS LIST
Finance
February 11, 2019 10:00 AM
Copeland Patience, Dee (Self), Austin, TX
Daniel, Katrina Chief Healthcare Officer (TRS), Austin
Feigen, David Early Childhood Policy Associate (Texans Care For Children), Austin, TX
Harrington, Katherine Marketing and communications (Myself, as the parent of a special
needs student), Austin, TX
Litzinger, Linda public policy specialist (Texas Parent to Parent), Austin, TX
McGuire, Kristin Governmental Relations Director (TCASE)
Moyer, Michael Professional Counselor (TCA Texas Counseling Association), S.A., TX
Saxton, Josette Mental Health Policy Director (Texas Care for Children), Austin, TX


--- layout: page title: About header-img: "img/about-bg.png" ---
I am a 29-year-old single father working as a cook and wanting to break into a new career. Hoping this is a good pathway to what I want to achieve.


Blog post 1
posted by rishabh
In this crash course I will cram as much about HTML that I can. This is meant for absolute beginners. If you are interested in learning HTML but know nothing, then you are in the right place. We will be creating a cheat sheet with all of the common HTML5 tags, attributes, semantic markup, etc. We will not be focusing on CSS in this video.
Read More
Blog post 2
posted by rishabh
In this crash course I will cram as much about HTML that I can. This is meant for absolute beginners. If you are interested in learning HTML but know nothing, then you are in the right place. We will be creating a cheat sheet with all of the common HTML5 tags, attributes, semantic markup, etc. We will not be focusing on CSS in this video.
Blog post 3
posted by rishabh
In this crash course I will cram as much about HTML that I can. This is meant for absolute beginners. If you are interested in learning HTML but know nothing, then you are in the right place. We will be creating a cheat sheet with all of the common HTML5 tags, attributes, semantic markup, etc. We will not be focusing on CSS in this video.


Little Builders
Little Builders is a community of passionate people who care about meaningful education and inequality problems. We want to create an effective learning experience for students and create an environment for them to innovate and build solutions that solve community problems around them.
I discovered Thai students spend 33% more time studying than students in developed countries. However, standardized PISA tests show we actually have lower performance. I myself have been through this education system for most of my life and realized that this needed to be changed.
Our approach is the integration of Design Thinking. Instead of telling students what to think, I teach them how to think, by providing hands-on experiences to create community-impact solutions because I believe the best way to learn is by doing. We create our own method by adapting Design Thinking to suit Thai students learning context.


| DOSE: |
|
insufflated |
Cocaine |
(powder / crystals) |
Hmm I don't know where or how to begin my story. I guess I could start with the first time I ever tried cocaine.
The start of high school was a rough time for me. My mother had passed away the previous year and my father was on his death bed now. I had always hung out with people that were much older then me and much more experienced then me with drugs. Drugs were always around in the neighbourhood that I lived in, whatever you wanted could be gotten. At least that was the way it seemed with my friends.
The first time I tried coke, me and a cousin of my mothers boyfriend were hanging out near the boardwalk.  He pulled the bag out and asked if I wanted to try some, now I had never said no to anything in my life and decided to go ahead and see what it was like.  That day I only tried it once more and then that was it for a few years.
The next time I had the chance to purchase some coke I was working at a Dunkin Donuts in a lower income area in NJ. Most of the people I worked with unbeknownst to me were coke heads. These were people who were doing 8balls every single night while at work to stay awake. Now imagine working at a Dunkin Donuts and having cops come in all night. You want to talk about paranoia! At first I wasn't interested in doing coke. I was fine being sober and drinking coffee to stay awake at night. That was all about to change pretty soon though. Chris who was one of the night bakers at the store was a big coke head.   You make some really good connections.
Anytime we needed coke it was delivered to work. My habit really started to develop while working at Dunkin Donuts. It was too the point where I needed the drug to live. I wasn't eating or sleeping just doing lines and lines of coke. At some points I would not be able to work without at least snorting a gram up each nostril. I would have cops coming in at all hours of the night for coffee trying to talk to me. As you know coke is good at numbing your throat so one night after railing 2 grams with my throat completely numb a cop decides to walk in at two in the morning and start talking to me. I was completely paranoid thought I was going to wind up in handcuffs. Luckily for me he had to run out on a call.
For about a year or so my days continued on like this. Finally after the store was closed down my habit stopped. So now a few years later it's starting back up again. Not as bad as before I won't let that happen. I started using it again about a week ago. I guess this is one monkey that I will never get off my back, but as long as I control it I shouldn't have any problems.
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.


PIZZA HUNT MENU
| Pizza | Toppings | Small | Medium | Large |
| Hunter's Delight | beef steak, red onions, BBQ sauce, tomatoes | 500 | 650 | 800 |
| Chicken Raid | grilled chicken, tomatoes, red onions, mixed peppers | 500 | 600 | 700 |
| Veggie Seekers | mushroom, olives, pineapples, onions, tomatoes | 400 | 500 | 600 |
Below you can find crusts that suit your need with added cost alongside them
| CRUSTS | ADDITIONAL COST |
| Canine Nightmare( thick double layer crust ) | 200 |
| Rhino Hide( thick single layer crust) | 100 |
| Fisherman Smile( thin layer crust) | 50 |


Project Title:
MIT
Table of Contents
Description
Installation
Usage
Contributions
Testing
License
Questions
Description
Installation
Usage
Contributions
Testing
License
This project utilizes the following license: MIT
Questions
My GitHub profile is
Please contact me with questions:


--- layout: default title: Home ---
The Differential Line [github] algorithm is inspired by the way a number of biological things in nature grows. Among other things it is made to mimic the growth of the human brain, as well as a great number of plants. In brief; we start of with a number of connected nodes in a circle. Gradually we introduce new nodes on the line—prioritizing segments where the curve bends more sharply. Over time the curve grows increasingly intricate, but it never self-intersects.
If we start with a different shape, and draw the outside position of the object for each growth step, we can get an entirely different kind of system. This system shares the 3d like illusion created by the Orbitals algorithm.
Leaf3 [github] is a three dimensional implementation of the algorithm that was the inspiration behind the various network algorithms I've been working with.
Differential Surface [github] is a three dimensional implementation of the same ideas (more or less) that inspired the Differential algorithm, which I wrote a while back.
The faces of the mesh are affected by their neighboring faces over time—rejecting non-neighboring faces that are too close, and keeping a comfortable distance to their actual neighbors. The surface is gradually remeshed to account for it's growing surface area.
Another interesting addition to this system is to let the system grow towards an imagined nutrition source, or light source, of some kind. This results in strange fungi-like objects.
Orbitals [github] is inspired by the naive optimization process that Jared Tarbell has implemented in his "Happy Place" algorithm. Nodes are created in some, more or less structured arangement, before they start to make friends with their neighbors. Gradually the nodes make an effort to get closer to their friends, whilst at the same time keeping a comfortable distance from the nodes they have not befriended. The visualization is made by drawing lines betweeen pairs of friends as they walk around the canvas. Thus the final image is a history of all the friendships.
Meshx [github] is my first attempt at a three dimensional generative algorithm. The algorithm can grow from any number of seeds; either along another surface geometry, or freely in any direction. The algorithm grows by choosing random triangles on the surface of the structure and appending a triangular pyramid to that face. This gives the resulting geometry a ragged-looking appearance. I had no particular biological process in mind when I wrote this algorithm, but it turns out that it creates structures that look a lot like corals.
One of the first attempts I made at generative algorithms was a copy of this great little application. Recently I decided it was about time that I revisited this project, and below are a few of the results. As opposed to the algorithm in the link, my trees are generated pixel by pixel. That is, there are no pre-drawn parts. [github]
As you can see, if you examine the images a little, the trees take shapes that er neither realistic nor possible. Yet they look very much like trees at first glance.
The background is another algorithm of mine called Linetrace.
Differential Mesh [github] is an extension of the Hyphae algorithm. I started working on it with the intention of mimicking the growth of (certain types of) lichen. The results, to me, are equal parts crystal-like and biological.
Hyphae [github] is an algorithm I wrote in an attempt to mimick the growth of roots. You can see a video of how the algorithm grows here. The algorithm centers around letting circles grow "next to each other" in such a way that no two circles overlap. The results are incredibly intricate and fractal-like, and they can be tweaked in a great number of ways.
After watching John Franzen drawing his incredibly fascinating "Each Line One Breath" drawings, I wanted to try doing somthing similar using code. After many failed results, I also ended up with a few versions I rather liked. They can hardly be said to behave in the same way as Franzen's drawings, as was the initial goal, however I find them equally interesting.
At some point I stumbled upon this great algorithm by Adam Runions et al. I have since spent some time replicating the algorithm itself, as well as trying to recreate the behaviour in other ways. As usual some of the results are similar, whereas others ... not so much.


| Home | Trees | Indices | Help |
|---|
|
|
This object wraps a dictionary, whos keys are _operations_ that we'd like to apply to a parameter array, and whose values are np integer arrays which index the parameter array appropriately.
A model instance will contain one instance of this class for each thing that needs indexing (i.e. constraints, ties and priors). Parameters within the model constain instances of the ParameterIndexOperationsView class, which can map from a 'local' index (starting 0) to this global index.
Here's an illustration:
#======================================================================= model : 0 1 2 3 4 5 6 7 8 9 key1: 4 5 key2: 7 8 param1: 0 1 2 3 4 5 key1: 2 3 key2: 5 param2: 0 1 2 3 4 key1: 0 key2: 2 3 #=======================================================================
The views of this global index have a subset of the keys in this global (model) index.
Adding a new key (e.g. a constraint) to a view will cause the view to pass the new key to the global index, along with the local index and an offset. This global index then stores the key and the appropriate global index (which can be seen by the view).
See also: ParameterIndexOperationsView
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
Inherited from |
|
|||
_offset = 0
|
|
|||
| size | |||
|
Inherited from |
|
x.__init__(...) initializes x; see help(type(x)) for signature
|
Returns a list of properties, such that each entry in the list corresponds to the element of the index given. Example: let properties: 'one':[1,2,3,4], 'two':[3,5,6] >>> properties_for([2,3,5]) [['one'], ['one', 'two'], ['two']] |
Return a dictionary, containing properties as keys and indices as index Thus, the indices for each constraint, which is contained will be collected as one dictionary Example: let properties: 'one':[1,2,3,4], 'two':[3,5,6] >>> properties_dict_for([2,3,5]) {'one':[2,3], 'two':[3,5]} |
str(x)
|
|
size
|
| Home | Trees | Indices | Help |
|---|
| Generated by Epydoc 3.0.1 on Tue Jul 4 11:59:32 2017 | http://epydoc.sourceforge.net |


Learning Node, Express, and Mongo
On June 16, 2017
I’ve finished my last exam on Wednesday, and I’ve been studying the Node.js Coursera Class since then.  So, now seems the perfect time to finish this course, to help me transition into a full-stack developer position as I’ve always planned.
What I’ve learned so far
So far I’m in week 3 of the 4 weeks’ MOOC, and I’ve learned about the following concepts:
- I learned how to create simple Node modules, and import them into other modules, to create a modular Node code.
- I also learned about Express.js and how to set up a basic server using it.
- Then I learned about MongoDB, and I really enjoyed the flexibility of the NoSQL DBs, it’s a lot more flexible and scalable than the SQL DBs that I’ve dealt with in the past. Here’s the code I wrote for that.
- After that I learned about Mongoose, and how to use it to impose a schema and a model on the collections in the MongoDB. Here’s the code I wrote for that.
- Then I connected the Express server written earlier to the Mongoose models, to create a fully functional RESTful APIs. Here’s the code I wrote for that.
What’s next
Next, I’ll be learning about:
- Basic user authentication.
- Cookies, and Express Sessions.
- Using Passport to authenticate users using their social media accounts.
- HTTPS and secure communication.
- Backend as a service.
- And I’ll finish that course by integrating the AngularJS/ionic app I’ve constructed in the past with the newly created backend.
How soon I’ll finish this
I think if I kept learning with the same pace I’m going now, I might be able to finish this by next Friday. Anyway, I’m more focused on learning the concepts behind everything in that course more than finishing it quickly, as I don’t have an actual CS background, and most of the concepts taught here are new to me. That’s why I think that understanding the meaning behind everything we do in this course is more important than following the instructions in building the app. I find it also important to read the external resources provided after each module, that helps me learn more about the tools and frameworks we are using in a more general sense, instead of just understanding the basics taught for the purpose of completing the restaurant app that we’re building in this course.
What’s next
After finishing that course, I’ll now have backend knowledge, and I’ll have developed a fully functional restaurant web/hybrid app. So, I might also build a couple of demos one using MEAN, and the other using MERN; to refresh my memory on both Angular and React.
After that I’ll continue working, and freelancing. Also, I’ll continue working on a side project that I’ve been working on in hopes of having a working demo before startup weekend this year.
Cheers! :)


My Generated Blog!
Index and Archive
Welcome to my blog! All the posts were generated procedurally...
Back to Index


Archive each currently loaded conversation
Archive each visible conversation
Archive the first conversation


Class: ActionDispatch::SSL
| Inherits: |
Object
|
| Defined in: |
Overview
This middleware is added to the stack when `config.force_ssl = true`, and
is passed the options set in config.ssl_options
. It does three
jobs to enforce secure HTTP requests:
1. TLS redirect: Permanently redirects http:// requests to https://
with the same URL host, path, etc. Enabled by default. Set `config.ssl_options`
to modify the destination URL
(e.g. `redirect: { host: "secure.widgets.com", port: 8080 }`), or set
`redirect: false` to disable this feature.
2. Secure cookies: Sets the `secure` flag on cookies to tell browsers they
mustn't be sent along with http:// requests. Enabled by default. Set
`config.ssl_options` with `secure_cookies: false` to disable this feature.
3. HTTP Strict Transport Security (HSTS): Tells the browser to remember
this site as TLS-only and automatically redirect non-TLS requests.
Enabled by default. Configure `config.ssl_options` with `hsts: false` to disable.
Set config.ssl_options
with `hsts: { … }` to configure HSTS:
* `expires`: How long, in seconds, these settings will stick. The minimum
required to qualify for browser preload lists is `18.weeks`. Defaults to
`180.days` (recommended).
* `subdomains`: Set to `true` to tell the browser to apply these settings
to all subdomains. This protects your cookies from interception by a
vulnerable site on a subdomain. Defaults to `false`.
* `preload`: Advertise that this site may be included in browsers'
preloaded HSTS lists. HSTS protects your site on every visit *except the
first visit* since it hasn't seen your HSTS header yet. To close this
gap, browser vendors include a baked-in list of HSTS-enabled sites.
Go to https://hstspreload.appspot.com to submit your site for inclusion.
Defaults to `false`.
To turn off HSTS, omitting the header is not enough. Browsers will remember the original HSTS directive until it expires. Instead, use the header to tell browsers to expire HSTS immediately. Setting hsts: false is a shortcut for `hsts: { expires: 0 }`.
Requests can opt-out of redirection with exclude
:
config. = { redirect: { exclude: -> request { request.path =~ /healthcheck/ } } }
Constant Summarycollapse
- HSTS_EXPIRES_IN =
-
Default to 180 days, the low end for www.ssllabs.com/ssltest/ and greater than the 18-week requirement for browser preload lists.
15552000
Class Method Summary collapse
- .default_hsts_options
-
.new(app, redirect: {}, hsts: {}, secure_cookies: true, **options) ⇒ SSL
constructor
a new instance of SSL
Instance Method Summary collapse
- #build_hsts_header(hsts) private
- #call(env)
- #flag_cookies_as_secure!(headers) private
- #https_location_for(request) private
- #normalize_hsts_options(options) private
- #redirect_to_https(request) private
- #set_hsts_header!(headers) private
Constructor Details
.new(app, redirect: {}, hsts: {}, secure_cookies: true, **options) ⇒ SSL
a new instance of SSL
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78
# File 'actionpack/lib/action_dispatch/middleware/ssl.rb', line 51
def initialize(app, redirect: {}, hsts: {}, secure_cookies: true, **) @app = app if [:host] || [:port] ActiveSupport::Deprecation.warn <<-end_warning.strip_heredoc The `:host` and `:port` options are moving within `:redirect`: `config.ssl_options = { redirect: { host: …, port: … } }`. end_warning @redirect = .slice(:host, :port) else @redirect = redirect end @exclude = @redirect && @redirect[:exclude] || proc { !@redirect } @secure_cookies = if hsts != true && hsts != false && hsts[:subdomains].nil? hsts[:subdomains] = false ActiveSupport::Deprecation.warn <<-end_warning.strip_heredoc In Rails 5.1, The `:subdomains` option of HSTS config will be treated as true if unspecified. Set `config.ssl_options = { hsts: { subdomains: false } }` to opt out of this behavior. end_warning end @hsts_header = build_hsts_header((hsts)) end
Class Method Details
.default_hsts_options
[ GitHub ]47 48 49
# File 'actionpack/lib/action_dispatch/middleware/ssl.rb', line 47
def self. { expires: HSTS_EXPIRES_IN, subdomains: false, preload: false } end
Instance Method Details
#build_hsts_header(hsts) (private)
[ GitHub ]114 115 116 117 118 119
# File 'actionpack/lib/action_dispatch/middleware/ssl.rb', line 114
def build_hsts_header(hsts) value = "max-age=#{hsts[:expires].to_i}" value << "; includeSubDomains" if hsts[:subdomains] value << "; preload" if hsts[:preload] value end
#call(env)
[ GitHub ]80 81 82 83 84 85 86 87 88 89 90 91 92
# File 'actionpack/lib/action_dispatch/middleware/ssl.rb', line 80
def call(env) request = Request.new env if request.ssl? @app.call(env).tap do |status, headers, body| set_hsts_header! headers headers if @secure_cookies end else return redirect_to_https request unless @exclude.call(request) @app.call(env) end end
#flag_cookies_as_secure!(headers) (private)
[ GitHub ]121 122 123 124 125 126 127 128 129 130 131 132 133
# File 'actionpack/lib/action_dispatch/middleware/ssl.rb', line 121
def (headers) if = headers["Set-Cookie".freeze] = .split("\n".freeze) headers["Set-Cookie".freeze] = .map { || if !~ /;\s*secure\s*(;|$)/i "#{}; secure" else end }.join("\n".freeze) end end
#https_location_for(request) (private)
[ GitHub ]142 143 144 145 146 147 148 149 150
# File 'actionpack/lib/action_dispatch/middleware/ssl.rb', line 142
def https_location_for(request) host = @redirect[:host] || request.host port = @redirect[:port] || request.port location = "https://#{host}" location << ":#{port}" if port != 80 && port != 443 location << request.fullpath location end
#normalize_hsts_options(options) (private)
[ GitHub ]99 100 101 102 103 104 105 106 107 108 109 110 111
# File 'actionpack/lib/action_dispatch/middleware/ssl.rb', line 99
def () case # Explicitly disabling HSTS clears the existing setting from browsers # by setting expiry to 0. when false self.class..merge(expires: 0) # Default to enabled, with default options. when nil, true self.class. else self.class..merge() end end
#redirect_to_https(request) (private)
[ GitHub ]135 136 137 138 139 140
# File 'actionpack/lib/action_dispatch/middleware/ssl.rb', line 135
def redirect_to_https(request) [ @redirect.fetch(:status, 301), { "Content-Type" => "text/html", "Location" => https_location_for(request) }, @redirect.fetch(:body, []) ] end
#set_hsts_header!(headers) (private)
[ GitHub ]95 96 97
# File 'actionpack/lib/action_dispatch/middleware/ssl.rb', line 95
def set_hsts_header!(headers) headers["Strict-Transport-Security".freeze] ||= @hsts_header end


The Jabber server has the ability to restrict the amount of bandwidth a
client can use, which can be setup using the options on this page :
- Excessive connection handling
If this is enabled, the server will only allow a client to make at most a
chosen number of requests within a chosen time period.
- Karma mode
For this option, you can choose for the server not to enforce any
per-client traffic limits, choose one of the three pre-defined limit
settings (low, medium or high), or enter your own selected limits.
This final option should only be used if you are familiar with the
meanings of all the fields.


Students
Teachers
Classes
Specialities
your opinion is very important to us thank you create your note


|
||||||||||
| PREV NEXT | FRAMES NO FRAMES |
| Packages that use Element | |
|---|---|
| ukim.finki.mps.delay_function_generator |
| Uses of Element in ukim.finki.mps.delay_function_generator |
|---|
| Fields in ukim.finki.mps.delay_function_generator declared as Element | |
|---|---|
private Element |
Executable.used_elements
elements this instruction affects such as registers or memory locations they should not be used by any other instruction in the delay function, and should be declared available for the delay function, in the case of registers explicitly condition-less, in the case of memory the function should prompt the user, for the addresses and amount |
| Methods in ukim.finki.mps.delay_function_generator that return Element | |
|---|---|
private Element[] |
CodeBuilder.removeUsedRegisters(Element[] elements_usable,
java.lang.String... registers)
removes the specified register from the array of elements on our disposal, does not change the original array |
| Methods in ukim.finki.mps.delay_function_generator with parameters of type Element | |
|---|---|
private Executable |
CodeBuilder.buildDelayFunction(long min_time,
long max_time,
Element[] elements_usable,
int instruction_limit)
the method to be used for generating delay functions with specific length of instructions specifies all the input parameters needed |
DelayFunction |
CodeBuilder.buildDelayFunction(long min_time,
long max_time,
java.lang.String mP,
Element[] elements_usable,
boolean ret_is_required)
just used to set the default value of res to null |
private DelayFunction |
CodeBuilder.buildDelayFunction(long min_time,
long max_time,
java.lang.String mP,
Element[] elements_usable,
DelayFunction res,
boolean ret_is_required)
the method to be used for generating delay functions this method will try to make a function with least possible instructions specifies all the input parameters needed |
private Executable |
CodeBuilder.buildLoop(long min_time,
long max_time,
Element[] elements_usable,
int instruction_limit,
int nested_loops_counter)
the method stub to be used for generating a loop specifies all the input parameters needed |
private Loop |
CodeBuilder.buildLoopByDeterminingInitValue(int min_iterations,
int max_iterations,
long min_time,
long max_time,
Element[] elements_usable,
int instruction_limit,
int nested_loops_counter,
java.lang.String reg_or_reg_pair,
int loop_type)
this method is used to generate loops it will try every possible number of iterations in the interval[min_iter,max_iter] for this loop's logic in order to get it's execution time in the interval [min_time,max_time], |
java.util.ArrayList<InstructionData> |
InstructionSet.getAllAvailableInstructions(Element[] elements_usable)
this function will take all the arguments, separate the instructions that we can use out of the whole instruction set of the mP with respect to the elements_usable, |
private void |
CodeBuilder.precomputeAllPossibleDurations(Element[] elements_usable,
int instruction_limit)
this function will take all the arguments, separate the instructions that we can use out of the whole instruction set of the mP with respect to the elements_usable, and will then calculate all possible duration of instructions segments of maximum instructions to instruction limit, and store that information in the possible_durations array |
private Element[] |
CodeBuilder.removeUsedRegisters(Element[] elements_usable,
java.lang.String... registers)
removes the specified register from the array of elements on our disposal, does not change the original array |
void |
Main.test(long min_time,
long max_time,
Element[] elements_usable,
boolean ret_is_required)
use this for testing |
void |
Main.testWithStep(long repetition,
long start,
long step,
Element[] elements_usable,
boolean ret_is_required,
long fault_tollerance)
|
| Constructors in ukim.finki.mps.delay_function_generator with parameters of type Element | |
|---|---|
Elements(Element[] elements_usable)
constructor for when we want to create a stub-comparison object for determining whether or not we can use a specific instruction with the usable elements, used when we want to separate the available instructions out of the whole instruction set |
|
InstructionGroup(java.util.ArrayList<InstructionData> instuctions,
Element single,
Element pair)
constructor to be used to specify memory locations for the instructions , initialize the instructions to a the instruction array param |
|
||||||||||
| PREV NEXT | FRAMES NO FRAMES |


Class CoordinatorCompletionParticipantEngine
- java.lang.Object
-
- com.arjuna.wst11.messaging.engines.CoordinatorCompletionParticipantEngine
-
- All Implemented Interfaces:
com.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
public class CoordinatorCompletionParticipantEngine extends java.lang.Object implements com.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
The coordinator completion participant state engine- Author:
- kevin
-
-
Constructor Summary
Constructors Constructor Description CoordinatorCompletionParticipantEngine(java.lang.String id, jakarta.xml.ws.wsaddressing.W3CEndpointReference coordinator, BusinessAgreementWithCoordinatorCompletionParticipant participant)
Construct the initial engine for the participant.CoordinatorCompletionParticipantEngine(java.lang.String id, jakarta.xml.ws.wsaddressing.W3CEndpointReference coordinator, BusinessAgreementWithCoordinatorCompletionParticipant participant, com.arjuna.webservices11.wsba.State state, boolean recovered)
Construct the engine for the participant in a specified state.
-
Method Summary
All Methods Instance Methods Concrete Methods Modifier and Type Method Description void
cancel(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType cancel, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the cancel event.com.arjuna.webservices11.wsba.State
cannotComplete()
Handle the cannot complete event.void
close(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType close, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the close event.void
compensate(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType compensate, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the compensate event.void
complete(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType complete, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the complete event.com.arjuna.webservices11.wsba.State
completed()
Handle the completed event.com.arjuna.webservices11.wsba.State
exit()
Handle the exit event.void
exited(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType exited, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the exited event.com.arjuna.webservices11.wsba.State
fail(javax.xml.namespace.QName exceptionIdentifier)
Handle the fail event.void
failed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType failed, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the failed event.jakarta.xml.ws.wsaddressing.W3CEndpointReference
getCoordinator()
Get the coordinator endpoint referencejava.lang.String
getId()
Get the coordinator id.BusinessAgreementWithCoordinatorCompletionParticipant
getParticipant()
Get the associated participant.void
getStatus(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType getStatus, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the getStatus event.boolean
isRecovered()
check whether this participant's details have been recovered from the logvoid
notCompleted(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType notCompleted, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the not completed event.void
recovery()
Handle the recovery event.void
soapFault(com.arjuna.webservices.SoapFault soapFault, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the soap fault event.void
status(org.oasis_open.docs.ws_tx.wsba._2006._06.StatusType status, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the status event.
-
-
-
Constructor Detail
-
CoordinatorCompletionParticipantEngine
public CoordinatorCompletionParticipantEngine(java.lang.String id, jakarta.xml.ws.wsaddressing.W3CEndpointReference coordinator, BusinessAgreementWithCoordinatorCompletionParticipant participant)
Construct the initial engine for the participant.- Parameters:
id
- The participant id.coordinator
- The coordinator endpoint reference.participant
- The participant.
-
CoordinatorCompletionParticipantEngine
public CoordinatorCompletionParticipantEngine(java.lang.String id, jakarta.xml.ws.wsaddressing.W3CEndpointReference coordinator, BusinessAgreementWithCoordinatorCompletionParticipant participant, com.arjuna.webservices11.wsba.State state, boolean recovered)
Construct the engine for the participant in a specified state.- Parameters:
id
- The participant id.coordinator
- The coordinator endpoint reference.participant
- The participant.state
- The initial state.recovered
- true if the engine has been recovered from th elog otherwise false
-
-
Method Detail
-
cancel
public void cancel(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType cancel, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the cancel event.- Specified by:
cancel
in interfacecom.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
- Parameters:
cancel
- The cancel notification.map
- The addressing context.arjunaContext
- The arjuna context. Active -> Canceling Canceling -> Canceling Completing -> Canceling Completed -> Completed (resend Completed) Closing -> Closing Compensating -> Compensating Failing-Active -> Failing-Active (resend Fail) Failing-Canceling -> Failing-Canceling (resend Fail) Failing-Completing -> Failing-Completing (resend Fail) Failing-Compensating -> Failing-Compensating NotCompleting -> NotCompleting (resend CannotComplete) Exiting -> Exiting (resend Exit) Ended -> Ended (send Canceled)
-
close
public void close(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType close, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the close event.- Specified by:
close
in interfacecom.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
- Parameters:
close
- The close notification.map
- The addressing context.arjunaContext
- The arjuna context. Active -> Active (invalid state) Canceling -> Canceling (invalid state) Completing -> Completing (invalid state) Completed -> Closing Closing -> Closing Compensating -> Compensating (invalid state) Failing-Active -> Failing-Active (invalid state) Failing-Canceling -> Failing-Canceling (invalid state) Failing-Completing -> Failing-Completing (invalid state) Failing-Compensating -> Failing-Compensating (invalid state) NotCompleting -> NotCompleting (invalid state) Exiting -> Exiting (invalid state) Ended -> Ended (send Closed)
-
compensate
public void compensate(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType compensate, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the compensate event.- Specified by:
compensate
in interfacecom.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
- Parameters:
compensate
- The compensate notification.map
- The addressing context.arjunaContext
- The arjuna context. Active -> Active (invalid state) Canceling -> Canceling (invalid state) Completing -> Completing (invalid state) Completed -> Compensating Closing -> Closing (invalid state) Compensating -> Compensating Failing-Active -> Failing-Active (invalid state) Failing-Canceling -> Failing-Canceling (invalid state) Failing-Completing -> Failing-Completing (invalid state) Failing-Compensating -> Failing-Compensating (resend Fail) NotCompleting -> NotCompleting (invalid state) Exiting -> Exiting (invalid state) Ended -> Ended (send Compensated)
-
complete
public void complete(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType complete, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the complete event.- Specified by:
complete
in interfacecom.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
- Parameters:
complete
- The complete notification.map
- The addressing context.arjunaContext
- The arjuna context. Active -> Completing Canceling -> Canceling Completing -> Completing Completed -> Completed (resend Completed) Closing -> Closing Compensating -> Compensating Failing-Active -> Failing-Active (resend Fail) Failing-Canceling -> Failing-Canceling (resend Fail) Failing-Completing -> Failing-Completing (resend Fail) Failing-Compensating -> Failing-Compensating NotCompleting -> NotCompleting (resend CannotComplete) Exiting -> Exiting (resend Exit) Ended -> Ended (send Fail)
-
exited
public void exited(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType exited, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the exited event.- Specified by:
exited
in interfacecom.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
- Parameters:
exited
- The exited notification.map
- The addressing context.arjunaContext
- The arjuna context. Active -> Active (invalid state) Canceling -> Canceling (invalid state) Completing -> Completing (invalid state) Completed -> Completed (invalid state) Closing -> Closing (invalid state) Compensating -> Compensating (invalid state) Failing-Active -> Failing-Active (invalid state) Failing-Canceling -> Failing-Canceling (invalid state) Failing-Completing -> Failing-Completing (invalid state) Failing-Compensating -> Failing-Compensating (invalid state) NotCompleting -> NotCompleting (invalid state) Exiting -> Ended Ended -> Ended
-
failed
public void failed(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType failed, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the failed event.- Specified by:
failed
in interfacecom.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
- Parameters:
failed
- The failed notification.map
- The addressing context.arjunaContext
- The arjuna context. Active -> Active (invalid state) Canceling -> Canceling (invalid state) Completing -> Completing (invalid state) Completed -> Completed (invalid state) Closing -> Closing (invalid state) Compensating -> Compensating (invalid state) Failing-Active -> Ended Failing-Canceling -> Ended Failing-Completing -> Ended Failing-Compensating -> Ended NotCompleting -> NotCompleting (invalid state) Exiting -> Exiting (invalid state) Ended -> Ended
-
notCompleted
public void notCompleted(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType notCompleted, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the not completed event.- Specified by:
notCompleted
in interfacecom.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
- Parameters:
notCompleted
- The not completed notification.map
- The addressing context.arjunaContext
- The arjuna context. Active -> Active (invalid state) Canceling -> Canceling (invalid state) Completing -> Completing (invalid state) Completed -> Completed (invalid state) Closing -> Closing (invalid state) Compensating -> Compensating (invalid state) Failing-Active -> Failing-Active (invalid state) Failing-Canceling -> Failing-Canceling (invalid state) Failing-Completing -> Failing-Completing (invalid state) Failing-Compensating -> Failing-Compensating (invalid state) NotCompleting -> Ended Exiting -> Exiting (invalid state) Ended -> Ended
-
getStatus
public void getStatus(org.oasis_open.docs.ws_tx.wsba._2006._06.NotificationType getStatus, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the getStatus event.- Specified by:
getStatus
in interfacecom.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
- Parameters:
getStatus
- The getStatus notification.map
- The addressing context.arjunaContext
- The arjuna context.
-
status
public void status(org.oasis_open.docs.ws_tx.wsba._2006._06.StatusType status, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the status event.- Specified by:
status
in interfacecom.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
- Parameters:
status
- The status type.map
- The addressing context.arjunaContext
- The arjuna context.
-
recovery
public void recovery()
Handle the recovery event. Active -> Active (invalid state) Canceling -> Canceling (invalid state) Completed -> Completed (resend completed) Closing -> Closing (invalid state) Compensating -> Compensating (invalid state) Failing-Active -> Failing-Active (invalid state) Failing-Canceling -> Failing-Canceling (invalid state) Failing-Compensating -> Failing-Compensating (invalid state) NotCompleting -> NotCompleting (invalid state) Exiting -> Exiting (invalid state) Ended -> Ended (invalid state)
-
soapFault
public void soapFault(com.arjuna.webservices.SoapFault soapFault, org.jboss.ws.api.addressing.MAP map, com.arjuna.webservices11.wsarj.ArjunaContext arjunaContext)
Handle the soap fault event.- Specified by:
soapFault
in interfacecom.arjuna.webservices11.wsba.CoordinatorCompletionParticipantInboundEvents
- Parameters:
soapFault
- The soap fault.map
- The addressing context.arjunaContext
- The arjuna context.
-
completed
public com.arjuna.webservices11.wsba.State completed()
Handle the completed event. Active -> Active (invalid state) Canceling -> Canceling (invalid state) Completing -> Completed Completed -> Completed Closing -> Closing (invalid state) Compensating -> Compensating (invalid state) Failing-Active -> Failing-Active (invalid state) Failing-Canceling -> Failing-Canceling (invalid state) Failing-Completing -> Failing-Completing (invalid state) Failing-Compensating -> Failing-Compensating (invalid state) Exiting -> Exiting (invalid state) NotCompleting -> NotCompleting (invalid state) Ended -> Ended (invalid state)
-
exit
public com.arjuna.webservices11.wsba.State exit()
Handle the exit event. Active -> Exiting Canceling -> Canceling (invalid state) Completing -> Exiting Completed -> Completed (invalid state) Closing -> Closing (invalid state) Compensating -> Compensating (invalid state) Failing-Active -> Failing-Active (invalid state) Failing-Canceling -> Failing-Canceling (invalid state) Failing-Completing -> Failing-Completing (invalid state) Failing-Compensating -> Failing-Compensating (invalid state) Exiting -> Exiting NotCompleting -> NotCompleting (invalid state) Ended -> Ended (invalid state)
-
fail
public com.arjuna.webservices11.wsba.State fail(javax.xml.namespace.QName exceptionIdentifier)
Handle the fail event. Active -> Failing-Active Canceling -> Failing-Canceling Completing -> Failing-Completing Completed -> Completed (invalid state) Closing -> Closing (invalid state) Compensating -> Failing-Compensating Failing-Active -> Failing-Active Failing-Canceling -> Failing-Canceling Failing-Completing -> Failing-Completing Failing-Compensating -> Failing-Compensating NotCompleting -> NotCompleting (invalid state) Exiting -> Exiting (invalid state) Ended -> Ended (invalid state)
-
cannotComplete
public com.arjuna.webservices11.wsba.State cannotComplete()
Handle the cannot complete event. Active -> NotCompleting Canceling -> Canceling (invalid state) Completing -> NotCompleting Completed -> Completed (invalid state) Closing -> Closing (invalid state) Compensating -> Compensating (invalid state) Failing-Active -> Failing-Active (invalid state) Failing-Canceling -> Failing-Canceling (invalid state) Failing-Completing -> Failing-Completing (invalid state) Failing-Compensating -> Failing-Compensating (invalid state) NotCompleting -> NotCompleting Exiting -> Exiting (invalid state) Ended -> Ended (invalid state)
-
getId
public java.lang.String getId()
Get the coordinator id.- Returns:
- The coordinator id.
-
getCoordinator
public jakarta.xml.ws.wsaddressing.W3CEndpointReference getCoordinator()
Get the coordinator endpoint reference- Returns:
- The coordinator endpoint reference
-
getParticipant
public BusinessAgreementWithCoordinatorCompletionParticipant getParticipant()
Get the associated participant.- Returns:
- The associated participant.
-
isRecovered
public boolean isRecovered()
check whether this participant's details have been recovered from the log- Returns:
- true if the participant is recovered otherwise false
-
-


Memorize every word which you don't know but everyone else does!
- Lorem Ipsum is simply dummy text of the printing and typesetting industry.
- Lorem Ipsum is simply dummy text of the printing and typesetting industry.
- Lorem Ipsum is simply dummy text of the printing and typesetting industry.
- Lorem Ipsum is simply dummy text of the printing and typesetting industry.


The method name that identifies this DID method SHALL be: peer
A DID that uses this method MUST begin with the following prefix: did:peer:
.
Per the DID specification, this string MUST be in lowercase. The remainder of the DID, after the prefix,
is the method specific identifier (MSI) described below.
This DID method applies to any identity management implementation that meets the following two requirements:
The peer DID scheme is defined by the following ABNF (see [[RFC5234]] for syntax):
peer-did = "did:peer:" numalgo transform encnumbasis numalgo = "0" / "1" transform = "z" encnumbasis = 46*BASE58BTC
Peer DIDs use an underlying number with high entropy, called the numeric basis, as the source of their
uniqueness. There are two methods for generating this number, as described in the
next section of this spec. These methods are represented in the DID value with numalgo
== 0
or numalgo
== 1
.
To build the full MSI, the raw bytes of the numeric basis are prefixed with a multicodec descriptor that makes those bytes
self-describing. This descriptor plus the raw bytes are then transformed to text in the manner associated with
transform
. This yields encnumbasis
in the ABNF.
In this version of the spec, the multicodec descriptor for numalgo
== 0
is
dependent on key type and exactly matches the descriptor that would be used for the same value in did:key
.
The multicodec descriptor for numalgo
== 1
is byte pair 0x12 0x20
, which says
that what follows is a SHA2-256 hash, 32 bytes long. (The size is included because, although SHA-256 is known
to produce 32-byte digests, other hash algorithms have variable-length output, and we could change the hash
algorithm in a future version of the spec.) The transform
is
base58, represented by the multibase prefix z
.
BASE58BTC
in the ABNF means the Bitcoin base58 character inventory;
for brevity, we omit the expansion--but see the matching regex for details.
The format of the DID value is intended to be future-proof, offering three expandable self-describing choices.
Future versions of the spec may describe additional methods of generating the numeric basis; each new method
should be associated with the next unused numalgo
decimal digit when it is defined. Likewise,
future versions of the spec may choose a different way to transform raw bytes to text, or a different format
for the raw bytes of the numeric basis; these should be reflected in updated values of transform
or of the multicodec descriptor at the front of the transformed bytes, respectively.
Base58 is case-sensitive; in this version of the spec, peer DIDs MUST be compared with a
case-sensitive algorithm and MUST NOT be normalized in case. The more general rule is that case sensitivity
derives from transform
, so routines that process multiple versions of peer DIDs MUST derive their
case sensitivity rules from the corresponding properties of whatever transform
a particular peer
DID uses.
The unique numeric basis underlying a Peer DID MUST be generated in one of the following two ways:
If numalgo
== 0
, a single keypair is chosen, having all possible privileges with respect
to the DID. The public key value for this pair is the numeric basis of the DID. The genesis version of the DID
doc is considered to be empty, granting all privileges to this key (and algorithmic derivations thereof, to
provide key agreement versus signing and so forth). The DID doc offers no endpoint. This makes the DID
functionally equivalent to a did:key value, and visually similar, except that a peer DID will have the numeric
algorithm as a prefix, before the multibase encoded, multicodec-encoded public key. For example, did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH
is equivalent to did:peer:0z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH
. The did:peer version differs
in that it is upgradeable to a dynamically updatable DID with full DID doc and endpoints, simply using deltas,
as long as the first delta is authenticated by the inception key.
id
property or its value). This lets the doc be created without
knowing the DID's value in advance. Suppressing the DID value creates a stored variant of peer
DID doc data, as opposed to the resolved variant that would have an actual DID value in the root
id
property. (In either the stored or resolved variant of the doc, anywhere else that the DID
value would appear, it should appear as a relative reference rather than an absolute value. For example,
eachcontroller
property of a publicKey that is owned by this DID would say
"controller": "#id"
.)
By hashing the stored variant, we avoid the circular problem of including the DID in the data that's being hashed. This means that a peer DID doc must be resolved by converting a stored variant of DID doc data into a resolved variant by inserting the value of the DID being resolved.
By deriving the numeric basis of the DID from the genesis version of the DID doc, the DID can begin its lifecycle with any number of keys and endpoints, including protective M-of-N policies. The inception key is the part of the genesis state that's true bedrock; all other information is optional and can be thought of as a sort of pre-rotation orpre-evolution, initiated by the inception key, to a more complex state.
The root of trust for peer DIDs is the entropy in the inception key. The inception key MUST be new for each DID; it MUST NOT ever be reused--and it must be the case that anyone observing the public half of the inception key cannot somehow derive or steal the private half. This guarantees that nobody other than the holder of the inception key could have created the genesis version of the DID doc. Because only the inception key has the privilege of sharing the DID doc with a peer, no other key holder can establish the relationship contrary to the intent of the inception key holder. This gives peer DIDs a self-certifying property that is vital to cybersecurity of all DIDs. Any DID method that does not guarantee the chain of custody of the DID between when it is created and when it is shared (e.g., written to a ledger or given to a peer) lacks this quality and is susceptible to attacks early in the DID's lifecycle. See this github issue for more discussion.
Correctly recognizing and handling peer DIDs as strings is a Layer 1 feature.
A valid peer
DID might be:
did:peer:1zQmZMygzYqNwU6Uhmewx5Xepf2VLp5S4HLSwwgf2aiKZuwa
Peer DIDs consist entirely of printable ASCII characters and in this version of the spec are exactly 57
characters long. They have no whitespace, and the only punctuation they use is the :
character. When
rendering in columns with a constrained width, they could be hyphenated one or more times as needed; the hyphens
would not be confused with meaningful delimiters, and the final character of the DID would be easy to find.
They could also be rendered in a short form with the middle of the long base58 section elided, if it is not
necessary to compare them with precision: did:peer:1z6Tx...WzJJq
. The ellipsis should not obscure
the prefix or the initial or final few characters of encnumbasis
, to preserve enough info for
casual distinction. This might be a useful rendering in log files, for example.
A convenient regex to match peer
DIDs is:
^did:peer:[01](z)([1-9a-km-zA-HJ-NP-Z]{46})$
A match against this regex places numalgo
(the algorithm for choosing a numeric basis) in
capture group 1, transform
in capture group 2, and encnumbasis
in capture group 3.
A few peer DID values are reserved and convey special meaning. See Reserved Values in the appendix.


8X8X8 Led cube
Dic 2020
Description
This is a led cube that was implemented using VHDL and a DE-2 board, the purpose of this project was to use the basic of digital systems and implement all the knowledge acquired about this topic. This led cube was made to follow the beat of a song, Into the void - kiss, and making different patterns by turning on and off its leds. All the project was made form scratch including the cube assembling. The leds used on this project were of 20mA and 3.2V
Used Technologies
- VHDL
- DE-2 Altera board
Links
What I learned
In this project I learned how to use multiplexers in order to select the output that the cube was going to have depending on a global clock. I also know how to make frequency dividers by implementing counters in VHDL and I know how to properly use the board DE-2. Finally learned to solve problems under pressure and to find different ways to get the desired result and choose which one was the best for being implemented.


Conflicts
April 14, 2015
A little while back me and a friend of mine had a bit of an altercation. We both had a lot going on at the time personally and on top of that we each had a couple drinks that night. There was really no main topic the fight was about. Essentially I think we both had so much built up anger we sort of lashed out at each other. We had a short shouting match back and forth and got a little tangled up, but nothing serious. I eventually walked away as we both probably needed to. The main emotion going through it was anger, but I also felt bad considering he was my best friend.
About 15 minutes later we met up and sat down and apologized. Things happen, especially among friends. Mainly we resolved the argument just using reason. After both of us were able to cool down, it was a lot easier dealing with the situation. If I were to go back, and my friend would probably say the same, I would have kept my cool better and not let my anger get the best of me. That is what led both of us over the edge. I usually am able to contain myself. Having a couple drinks that night also probably did not help us. Overall, I learned that conflicts will occur in your life. There is no such thing as a perfect life. Conflicts and issues are part of it and how you handle and react to them is the most important. Some conflicts can be avoided though and by following your own set of "best practices" you can probably stay away from a few.


instrument
Module
Module Summary
Description
The module instrument contains support for studying the resource usage in an Erlang runtime system. Currently, only the allocation of memory can be studied.
Note that this whole module is experimental, and the representations used as well as the functionality is likely to change in the future.
The instrument module interface was slightly changed in Erlang/OTP R9C.
To start an Erlang runtime system with instrumentation, use the +Mi* set of command-line arguments to the erl command (see the erts_alloc(3) and erl(1) man pages).
The basic object of study in the case of memory allocation is a memory allocation map. A memory allocation map contains a list of descriptors for each allocated memory block. Currently, a descriptor is a 4-tuple
{TypeNo, Address, Size, PidDesc}
where TypeNo is the memory block type number, Address is its place in memory, and Size is its size, in bytes. PidDesc is either a tuple {X,Y,Z} identifying the process which was executing when the block was allocated, or undefined if no process was executing. The pid tuple {X,Y,Z} can be transformed into a real pid by usage of the c:pid/3 function.
Various details about memory allocation:
Memory blocks are allocated both on the heap segment and on other memory segments. This can cause the instrumentation functionality to report very large holes. Currently the instrumentation functionality doesn't provide any support for distinguishing between holes between memory segments, and holes between allocated blocks inside memory segments. The current size of the process cannot be obtained from within Erlang, but can be seen with one of the system statistics tools, e.g., ps or top. The Solaris utility pmap can be useful. It reports currently mapped memory segments.
Overhead for instrumentation: When the emulator has been started with the "+Mim true" flag, each block is preceded by a 24 bytes large header on a 32-bit machine and a 48 bytes large header on a 64-bit machine. When the emulator has been started with the "+Mis true" flag, each block is preceded by an 8 bytes large header. These are the header sizes used by the Erlang 5.3/OTP R9C emulator. Other versions of the emulator may use other header sizes. The function block_header_size/1 can be used for retrieving the header size used for a specific memory allocation map. The time overhead for managing the instrumentation data is small.
Sizes presented by the instrumentation functionality are (by the emulator) requested sizes, i.e. neither instrumentation headers nor headers used by allocators are included.
Exports
allocator_descr(MemoryData, TypeNo) -> AllocDescr | invalid_type | "unknown"
Types
Returns the allocator description of the allocator that manages memory blocks of type number TypeNo used in MemoryData. Valid TypeNos are in the range returned by type_no_range/1 on this specific memory allocation map. If TypeNo is an invalid integer, invalid_type is returned.
block_header_size(MemoryData) -> int()
Types
Returns the memory block header size used by the emulator that generated the memory allocation map. The block header size may differ between different emulators.
class_descr(MemoryData, TypeNo) -> ClassDescr | invalid_type | "unknown"
Types
Returns the class description of the class that the type number TypeNo used in MemoryData belongs to. Valid TypeNos are in the range returned by type_no_range/1 on this specific memory allocation map. If TypeNo is an invalid integer, invalid_type is returned.
descr(MemoryData) -> DescrMemoryData
Types
Returns a memory allocation map where the type numbers (first element of Desc) have been replaced by type descriptions, and pid tuples (fourth element of Desc) have been replaced by real pids.
Types
Prints out the size of each hole (i.e., the space between allocated blocks) on the terminal. NOTE: Really large holes are probably holes between memory segments. The memory allocation map has to be sorted (see sort/1).
mem_limits(MemoryData) -> {Low, High}
Types
Returns a tuple {Low, High} indicating the lowest and highest address used. The memory allocation map has to be sorted (see sort/1).
memory_data() -> MemoryData | false
Types
Returns MemoryData (a the memory allocation map) if the emulator has been started with the "+Mim true" command-line argument; otherwise, false. NOTE:memory_data/0 blocks execution of other processes while the data is collected. The time it takes to collect the data can be substantial.
memory_status(StatusType) -> [StatusInfo] | false
Types
Returns a list of StatusInfo if the emulator has been started with the "+Mis true" or "+Mim true" command-line argument; otherwise, false.
See the read_memory_status/1 function for a description of the StatusInfo term.
read_memory_data(File) -> MemoryData | {error, Reason}
Types
Reads a memory allocation map from the file File and returns it. The file is assumed to have been created by store_memory_data/1. The error codes are the same as for file:consult/1.
read_memory_status(File) -> MemoryStatus | {error, Reason}
Types
Reads memory allocation status from the file File and returns it. The file is assumed to have been created by store_memory_status/1. The error codes are the same as for file:consult/1.
When StatusType is allocators, About is the allocator that the information is about. When StatusType is types, About is the memory block type that the information is about. Memory block types are not described other than by their name and may vary between emulators. When StatusType is classes, About is the memory block type class that information is presented about. Memory block types are classified after their use. Currently the following classes exist:
- process_data
- Erlang process specific data.
- binary_data
- Erlang binaries.
- atom_data
- Erlang atoms.
- code_data
- Erlang code.
- system_data
- Other data used by the system
When InfoName is sizes, Current, MaxSinceLast, and MaxEver are, respectively, current size, maximum size since last call to store_memory_status/1 or memory_status/1 with the specific StatusType, and maximum size since the emulator was started. When InfoName is blocks, Current, MaxSinceLast, and MaxEver are, respectively, current number of blocks, maximum number of blocks since last call to store_memory_status/1 or memory_status/1 with the specific StatusType, and maximum number of blocks since the emulator was started.
NOTE:A memory block is accounted for at "the first level" allocator. E.g. fix_alloc allocates its memory pools via ll_alloc. When a fix_alloc block is allocated, neither the block nor the pool in which it resides are accounted for as memory allocated via ll_alloc even though it is.
sort(MemoryData) -> MemoryData
Types
store_memory_data(File) -> true|false
Types
Stores the current memory allocation map on the file File. Returns true if the emulator has been started with the "+Mim true" command-line argument, and the map was successfully stored; otherwise, false. The contents of the file can later be read using read_memory_data/1. NOTE:store_memory_data/0 blocks execution of other processes while the data is collected. The time it takes to collect the data can be substantial.
store_memory_status(File) -> true|false
Types
Stores the current memory status on the file File. Returns true if the emulator has been started with the "+Mis true", or "+Mim true" command-line arguments, and the data was successfully stored; otherwise, false. The contents of the file can later be read using read_memory_status/1.
sum_blocks(MemoryData) -> int()
Types
Returns the total size of the memory blocks in the list.
type_descr(MemoryData, TypeNo) -> TypeDescr | invalid_type
Types
Returns the type description of a type number used in MemoryData. Valid TypeNos are in the range returned by type_no_range/1 on this specific memory allocation map. If TypeNo is an invalid integer, invalid_type is returned.
type_no_range(MemoryData) -> {Min, Max}
Types
Returns the memory block type number range used in MemoryData. When the memory allocation map was generated by an Erlang 5.3/OTP R9C or newer emulator, all integers T that satisfy Min <= T <= Max are valid type numbers. When the memory allocation map was generated by a pre Erlang 5.3/OTP R9C emulator, all integers in the range are not valid type numbers.


<> Front-end Web Developer / Student </>
Welcome to my portfolio page! I grew up in an Air Force family, and spent my childhood moving around the United States. I eventually came to call Herndon, VA my home and am a 2017 graduate of Herndon High School. I am currently attending Yale University in New Haven, CT where I am pursuing a B.S.E. in Electrical Engineering and Computer Science. I have previous experience in Java and I am currently studying HTML, CSS, Bootstrap, JQuery, and Javascript through Free Code Camp to learn web design. Feel free to check out my social media links in the Naviagation Bar.
See the Pen Albert Einstein by Josh Beasley (@joshbeasley) on CodePen.
Copyright © Josh Beasley 2017. All Rights Reserved.