Re: [Architecture] [UUF] Removing creation of inline JS script tags upon calling sendToClient()

2017-05-31 Thread Rasika Perera
+1 for . AFAIK there's no hard limitation in meta tags unless search engines cut off at some point for the SEO. On Wed, May 31, 2017 at 5:18 PM, Dakshika Jayathilaka wrote: > Hi All, > > IMHO if we are going forward with meta tag we need to think about HTML > validation as

Re: [Architecture] [IoT] Improvements to device grouping to allow shared users (non admin ) to control the devices

2017-05-31 Thread Ayyoob Hamza
> > > 1). Provide a way to map feature-permissions for the device types that are > being created using the API. > we can allow this capability to be used for the pluggable device type but I think we cannot allow to create new permissions during runtime, since this permission hierarchy is visible

Re: [Architecture] Force Delete Identity Providers

2017-05-31 Thread Prabath Siriwardena
On Wed, May 31, 2017 at 3:30 AM, Asela Pathberiya wrote: > > > On Wed, May 31, 2017 at 2:38 PM, Prabath Siriwardena > wrote: > >> >> >> On Wed, May 31, 2017 at 1:16 AM, Asela Pathberiya wrote: >> >>> >>> >>> On Mon, May 29, 2017 at 11:12 AM,

Re: [Architecture] [UUF] Removing creation of inline JS script tags upon calling sendToClient()

2017-05-31 Thread Dakshika Jayathilaka
Hi All, IMHO if we are going forward with meta tag we need to think about HTML validation as well. AFAIK according to the specification, we can't use value or data attrib with meta tags[1]. +1 for using content attrib. [1] https://www.w3.org/TR/html5/document-metadata.html#the-meta-element

Re: [Architecture] [UUF] Removing creation of inline JS script tags upon calling sendToClient()

2017-05-31 Thread SajithAR Ariyarathna
Hi Jerad, On Wed, May 31, 2017 at 5:12 PM, Jerad Rutnam wrote: > Hi Sajith, > > "value" attribute has a direct coupling with "name" attribute. That's why > I thought of changing it. But in that case I would suggest to use "content" > attribute instead, as other vendors use, > >

Re: [Architecture] Why we use timestampSkew default value as 300 seconds in identity.xml, why not 0 seconds.

2017-05-31 Thread Isura Karunaratne
Hi, On Wed, May 31, 2017 at 1:23 PM, Asela Pathberiya wrote: > > > On Wed, May 31, 2017 at 1:08 PM, Farasath Ahamed > wrote: > >> >> On Wed, May 31, 2017 at 12:28 PM, Thanuja Jayasinghe >> wrote: >> >>> Hi Dinali, >>> >>> Consider the

Re: [Architecture] Force Delete Identity Providers

2017-05-31 Thread Asela Pathberiya
On Wed, May 31, 2017 at 2:38 PM, Prabath Siriwardena wrote: > > > On Wed, May 31, 2017 at 1:16 AM, Asela Pathberiya wrote: > >> >> >> On Mon, May 29, 2017 at 11:12 AM, Harsha Thirimanna >> wrote: >> >>> >>> >>> On Wed, May 17, 2017 at 9:44

Re: [Architecture] Force Delete Identity Providers

2017-05-31 Thread Prabath Siriwardena
On Wed, May 31, 2017 at 1:16 AM, Asela Pathberiya wrote: > > > On Mon, May 29, 2017 at 11:12 AM, Harsha Thirimanna > wrote: > >> >> >> On Wed, May 17, 2017 at 9:44 AM, Prabath Siriwardena >> wrote: >> >>> At the moment we can't delete an

Re: [Architecture] Force Delete Identity Providers

2017-05-31 Thread Asela Pathberiya
On Mon, May 29, 2017 at 11:12 AM, Harsha Thirimanna wrote: > > > On Wed, May 17, 2017 at 9:44 AM, Prabath Siriwardena > wrote: > >> At the moment we can't delete an identity provider, if its associated >> with one or more service providers. >> >> Also - for

Re: [Architecture] [IS] IS 5.5.0 += Adaptive Authentication

2017-05-31 Thread Asela Pathberiya
On Wed, May 31, 2017 at 10:38 AM, Ruwan Abeykoon wrote: > > Hi Prabath, > > >> Please check whether my understanding is correct based on the following >> mail.. >> >> 1. We define set of ACR values at the framework level - which are >> agnostic to the inbound protocols. >> 2.

Re: [Architecture] Why we use timestampSkew default value as 300 seconds in identity.xml, why not 0 seconds.

2017-05-31 Thread Asela Pathberiya
On Wed, May 31, 2017 at 1:08 PM, Farasath Ahamed wrote: > > On Wed, May 31, 2017 at 12:28 PM, Thanuja Jayasinghe > wrote: > >> Hi Dinali, >> >> Consider the following calculation. >> >> expiry time = issuedTimeInMillis + validityPeriodMillis - >>

Re: [Architecture] Why we use timestampSkew default value as 300 seconds in identity.xml, why not 0 seconds.

2017-05-31 Thread Farasath Ahamed
On Wed, May 31, 2017 at 12:28 PM, Thanuja Jayasinghe wrote: > Hi Dinali, > > Consider the following calculation. > > expiry time = issuedTimeInMillis + validityPeriodMillis - > (System.currentTimeMillis() - timestampSkew) > > So actually token is valid for (validityPeriodMillis

[Architecture] [UUF] Removing creation of inline JS script tags upon calling sendToClient()

2017-05-31 Thread SajithAR Ariyarathna
Hi All, We are in the process of doing $subject. # What is sendToClient() function? Its a server-side JS function provided by UUF that can be used to send a server-side value to the client-side. function onGet(env) { sendToClient("contextPath", env.contextPath); } Which will produce

Re: [Architecture] Why we use timestampSkew default value as 300 seconds in identity.xml, why not 0 seconds.

2017-05-31 Thread Thanuja Jayasinghe
Hi Dinali, Consider the following calculation. expiry time = issuedTimeInMillis + validityPeriodMillis - (System.currentTimeMillis() - timestampSkew) So actually token is valid for (validityPeriodMillis + timestampSkew) seconds. This additional time is added to avoid the error occurred due to

[Architecture] Why we use timestampSkew default value as 300 seconds in identity.xml, why not 0 seconds.

2017-05-31 Thread Dinali Dabarera
Hi All, In our identity.xml the default timeStampScrew value is used as 300 seconds. Shouldn't this be 0 seconds? Because when we are getting a token from password grant type again and again *without a time delay*, the expiry time of the token increases than its accepted value because of this