+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
>
>
> 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
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,
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
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,
>
>
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
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
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
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
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.
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 -
>>
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
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
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
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
15 matches
Mail list logo