On Tue, Jan 10, 2017 at 12:06 PM, Malintha Amarasinghe
wrote:
> On Tue, Jan 10, 2017 at 12:03 PM, Bhathiya Jayasekara
> wrote:
>
>>
>> On Tue, Jan 10, 2017 at 11:53 AM, Malintha Amarasinghe <
>> malint...@wso2.com> wrote:
>>
>>> If we can fix this without
On Tue, Jan 10, 2017 at 12:03 PM, Bhathiya Jayasekara
wrote:
>
> On Tue, Jan 10, 2017 at 11:53 AM, Malintha Amarasinghe > wrote:
>
>> If we can fix this without breaking the user experience is ideal. But the
>> problem I see is how can we manage those
On Tue, Jan 10, 2017 at 11:53 AM, Malintha Amarasinghe
wrote:
> If we can fix this without breaking the user experience is ideal. But the
> problem I see is how can we manage those changes; are we going to do that
> in each and every query? If we miss one place that will
If we can fix this without breaking the user experience is ideal. But the
problem I see is how can we manage those changes; are we going to do that
in each and every query? If we miss one place that will introduce a bug. Is
there any way we can manage this in a central manner?
On Tue, Jan 10,
Hi All,
As described in [1] we need to configure username/password in
IsAnalytics-Publisher-wso2event-AuthenticationData.xml and
IsAnalytics-Publisher-wso2event-SessionData.xml files. How do we handle
when some user store has policies to change credentials periodically. Do we
have to change
IMO user experience is the most important thing and what ever the logic we
have implemented should not do any difference in end user experience.
Hence, keeping things simple, prefer using a space character if and only if
user has provided an empty string. Otherwise keep the default value.
We can say that the string we use is a reserved keyword. In any complex
system we have to have such restriction in order address these kind of
issues.
On Tue, Jan 10, 2017 at 11:23 AM, Malintha Amarasinghe
wrote:
>
>
> On Tue, Jan 10, 2017 at 11:10 AM, Akalanka Pagoda
On 10 January 2017 at 11:10, Akalanka Pagoda Arachchi
wrote:
> Replacing an empty string with a space is generally a bad practice in
> database perspective due to few reasons.
>
> 1. Issues with visibility (a DBA cannot tell the difference by directly
> looking at it)
> 2. As
On Tue, Jan 10, 2017 at 11:10 AM, Akalanka Pagoda Arachchi <
darsha...@wso2.com> wrote:
> Replacing an empty string with a space is generally a bad practice in
> database perspective due to few reasons.
>
> 1. Issues with visibility (a DBA cannot tell the difference by directly
> looking at it)
>
This did come up in discussion. Functionally speaking a space is no
different to an empty String, though technically they are different. So it
will be a trade off to ignore explicitly sent spaces by users.
On 10 January 2017 at 11:01, Madhawa Gunasekara wrote:
> So what will
Replacing an empty string with a space is generally a bad practice in
database perspective due to few reasons.
1. Issues with visibility (a DBA cannot tell the difference by directly
looking at it)
2. As Madhawa pointed out, space is a different character and when we
really want to represent a
So what will happen if the user sends a space? So It's better to add a
configuration to avoid these situations. then user can handle this. WDYT ?
On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha
wrote:
> To be more precise, if a user explicitly sends "" then we will
To be more precise, if a user explicitly sends "" then we will set the
value to space, enabling us to convert back to "".
But if the field is not set(ignored by the user) then the default NULL will
be saved. This will make things consistant across all DB's.
On 10 January 2017 at 10:41, Uvindra
Note that there is a clear break in the UX of the REST API if we allow pass
empty strings to Oracle(due to the conversion to NULL). Oracle treats "" as
NULL but this is incorrect in the REST/JSON world.
If a user enters an empty string "" they will expect to get "" back, which
will not happen
+1 to keep default as NULL instead of a space.
Having a space will require adding trimming logic to the underlying code
and methods like 'isNullOrEmpty' will bypass this string if there's a space.
Thanks,
Akalanka.
On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray wrote:
>
>
>
On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa wrote:
>
>
> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha
> wrote:
>
>> Setting a default value for empty fields being sent seems to be best.
>>
>> Furthermore we can have default values set in our
Hi Tharindu,
Yes. We can add this MongoDB user store as an extension to WSO2 Store.
Thanks,
Kathees
On Mon, Jan 9, 2017 at 5:33 PM, Tharindu Edirisinghe
wrote:
> Thanks for sharing the thread Vinod.
>
> In our project we would focus only on the user management.
>
> However
Hi Jose Maria,
Thank you very much for your contribution and for the detailed explanation
on how you have mapped the MongoDB concepts to implement. Analytics
RecordStores. We will go through the two pull requests you have sent us and
will share our thoughts.
Thanks,
Gimantha
On Mon, Jan 9,
Hi all,
Thanks for testing WSO2 Identity Server 5.3.0-RC3. This vote passed with 22
+1s and 0 -1s.
We will proceed with WSO2 Identity Server 5.3.0 release.
--
*Pulasthi Mahawithana*
Senior Software Engineer
WSO2 Inc., http://wso2.com/
Mobile: +94-71-5179022
Blog: http://blog.pulasthi.org
Hi,
Tested the following,
- Custom OAuth 2.0 grant-type
- Integrated Windows Authentication (IWA) with Kerberos
[+] Stable - go ahead and release
On Mon, Jan 9, 2017 at 2:55 PM, Pulasthi Mahawithana
wrote:
> Hi All,
>
> Tested the following,
>
>- Engaging
Thanks for sharing the thread Vinod.
In our project we would focus only on the user management.
However later we can integrate the analytics as well together to build a
complete usecase.
On Mon, Jan 9, 2017 at 5:20 PM, Vinod Kavinda wrote:
> Hi All,
> FYI, there is another
Hi All,
FYI, there is another attempt for using MongoDB with WSO2 Analytics. See
the Dev mail thread [1].
[1] - "[Dev] [MongoDB] MongoDB support for analytics"
On Mon, Jan 9, 2017 at 12:30 PM, Asantha Thilina
wrote:
> Hi all,
>
> I am willing to contribute and January
Hi All,
Tested the following,
- Engaging access policies in authentication flow
- Template XACML policies for authentication flow and rule based
provisioning
- XACML funtionalities and policy editor
- SCIM user list with attributes and other SCIM operations
- Prompt for missing
Hi,
Tested the following IS features.
1. PDF Support in IS analytics
2. Email notifications on Security Alerts in IS analytics
[+] Stable - go ahead and release
On Mon, Jan 9, 2017 at 1:14 PM, Rasika Perera wrote:
> Tested out component version 5.7.0 with IoT pack.
>
Tested following features in RC3
- Install API Manager 6.0.37 features with IS RC3 pack
- Tested API Creation, Application Creation, Key generation and API
Invocation in both super tenant and tenant mode
- Tested SSO of API Store and Publisher in both super tenant and tenant
mode
Hi,
Tested the following IS features with Oracle database.
1. Federation Facebook
- SAML to Facebook.
- OpenID to Facebook.
- PassiveSTS to Facebook.
- Claim Mappings.
2. Federation Google
- SAML to Google.
- OpenID to Google.
- PassiveSTS to Google.
Tested out component version 5.7.0 with IoT pack.
[+] Stable - go ahead and release
On Mon, Jan 9, 2017 at 1:00 PM, Ashen Weerathunga wrote:
> Hi,
>
> Tested the following IS Analytics features with IS Runtime,
>
>- Login attempts analytics
>- Login session analytics
Tested following features in RC3.
- XACML Rest profile
- Rule base provisioning
- Authorization Rules for SSO
- Dynamic Client Registration
[+] Stable : Go ahead and release
Thanks,
On Mon, Jan 9, 2017 at 1:00 PM, Ashen Weerathunga wrote:
> Hi,
>
> Tested the
Hi,I'm Jose Maria Alvarez, and I'm part of one of the biggest retailers in Spain, called "El Corte Ingles". As you may know, we have a project to include WSO API-GW in our current architecture, and as part of that, we faced a problem related to the fact that you don't support MongoDB as the
29 matches
Mail list logo