The goal of this document is to describe how the User Management will be implemented in the Unified Push Server. Currently there is only one user created by default when installing UPS. Having the possibility to create multiple users is a "Must Have" and should be manageable from the Admin Console. Some roles should also be introduced
# is the url for retrieve the openid configuration - normally the <server>/auth/realm/<realm_name> | |
discovery-url: http://localhost:8180/auth/realms/summit | |
# the client id for the 'client' application | |
client-id: go-rest | |
# the interface definition you wish the proxy to listen, all interfaces is specified as ':<port>' | |
listen: 127.0.0.1:4000 | |
# log all incoming requests | |
enable-logging: true | |
# log in json format |
#!/bin/bash | |
oc cluster down | |
docker rm -f bindmountproxy |
public class AddUserExample { | |
public static void main(String[] args) { | |
Settings settings = | |
new SettingsBuilder() | |
.logging(false) | |
.readInputrc(false) | |
.disableCompletion(true) | |
.disableHistory(true) |
//this is using promises. | |
dm.stores.demo.open().then( function( value ) { | |
var data = [ | |
{ | |
"id": 1, | |
"name": "Lea", | |
"type": "Skywalker" | |
} | |
]; |
console.log('Loading a web page'); | |
var page = require('webpage').create(); | |
var url = 'http://localhost:1947/'; | |
page.viewportSize = { | |
width: 1024, | |
height: 768 | |
}; | |
page.open(url, function (status) { | |
//Page is loaded! | |
var iz, i = 0, queue = {}; |
#AeroGear.AutoConfig
The idea of this utility is to provide a method to automatically configure the client side connections to server resources (Pipeline) via a request for the JSON config to the server from an AeroGear client.
Currently, to set up and use a single connection to the server (pipe) you can use the following:
// Set up a pipeline which contains one pipe using the default REST adapter
var userPipeline = AeroGear.Pipeline( "users" ),
users = userPipeline.pipes.users;
This document is intended to discuss a solution for AEROGEAR-645 "Add Query/Paging support on RESTful endpoints".
This dev-aerogear mail list thread was used as a starting point to gather requirements and ideas.
Lets just clarify the two concepts that we are dealing with here, Paging and Query.
Paging deals with limiting the number of results returned from a single request. One "page" can contain a certain number of items as the result of invoking a request, sometimes referred to the size of a page. Let say you want to limit you the number of result returned to 10 items, this could look something like this:
According to the CORS specification, to indicate an invalid CORS request one simply does not add any CORS specific headers to the response.
There are two situations with regards to CORS Preflight request where this might cause confusion:
- The request is using a HTTP Method that is not supported by the server
- The request contains headers that are not supported by the server
In both of these cases the response status would be 200, but there will be no CORS-specific response headers. Since there are no CORS-specific headers in the response, the browser assumes the request is invalid, and doesn’t make the actual request. For both of these situations the client would see the same error:
XMLHttpRequest cannot load http://corscontroller-danbev.rhcloud.com/aerogear-controller-demo/delorean. Origin http://corsclient-danbev.rhcloud.com is not allowed by Access-Control-Allow-Origin.
This document describes the server side interfaces for AeroGear. Since all interactions use the Http protocol the interfaces in question are resource URLs.
Some of the exposed resource URLs are specific to AeroGear, for example if AeroGear-Security is in use, then there are certain URL that are exposed by default. But for most of the resource URLs the actual composition of the URLs is specific to the server side application. This document's indent is to be a guide for users creating new RESTful server side applications as well as for client developers to know how to interact with RESTful applications (what request/responses will look like).
The APIs described in this document are based on Hypertext Transfer Protocol, version 1.1 and https is recommended. Please refer to the security section of this document for details why https is important.
A resource, or an endpoint, is identified by