Hi Kishanthan,
When we have the master-keys.yaml and secrets.properties yaml file path in
secure-vault.yaml configuration the end user do not need to override a
method to explain how the paths are taken but rather handled within the
secure vauilt implementation itself. So if the paths are
Hi Niranjan,
Ideally, the OSGi / non-OSGi check should happen at the secure vault
initialization phase. The rest of the execution should happen accordingly
without checking for OSGi / non-OSGi. However, if we delegate providing
other file paths (secret.properties, master-key.yaml) to relevant
Could you explain the advantage of this proposed approach based on OSGi vs
non-OSGi mode of execution?
On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara
wrote:
> Hi All,
>
> An example for a secure vault YAML configuration file is as shown below
> according to the current
Hi Jayanga,
On Fri, Mar 17, 2017 at 10:09 AM, Jayanga Dissanayake
wrote:
> Hi Niranjan,
>
> You are correct we should follow the same way as msf4j to detect whether
> it is OSGi mode or not.
> The properties suggested are to avoid the OSGi mode check in several
> places. With
Hi Niranjan,
You are correct we should follow the same way as msf4j to detect whether it
is OSGi mode or not.
The properties suggested are to avoid the OSGi mode check in several
places. With the suggested properties, secure-vault.yaml will have all the
information it needs for the
Hi Vidura,
We can identify whether it is in OSGi mode or non-OSGi mode by checking if
the bundleContext is set. If it is not set, then it is in non-OSGi mode.
This is the way we have done for msf4j. Any reason for this new approach?
Regards,
Nira
On Fri, Mar 17, 2017 at 9:37 AM, Lakshman
Hi Vidura,
On Fri, Mar 17, 2017 at 9:15 AM, Vidura Nanayakkara
wrote:
> Hi All,
>
> An example for a secure vault YAML configuration file is as shown below
> according to the current implementation.
>
> secretRepository:
> type: org.wso2.carbon.kernel.securevault.repository.
Hi Kasun,
On Thu, Mar 16, 2017 at 1:55 PM, KasunG Gajasinghe wrote:
>
>
> On Thu, Mar 16, 2017 at 8:50 AM, Pushpalanka Jayawardhana
> wrote:
>
>>
>>
>> On Thu, Mar 16, 2017 at 8:46 AM, Pushpalanka Jayawardhana > > wrote:
>>
>>> Hi All,
>>>
>>>
Hi All,
An example for a secure vault YAML configuration file is as shown below
according to the current implementation.
secretRepository:
type:
org.wso2.carbon.kernel.securevault.repository.DefaultSecretRepository
parameters:
privateKeyAlias: wso2carbon
keystoreLocation:
On Wed, Mar 15, 2017 at 6:50 AM, Thanuja Jayasinghe
wrote:
> Hi Nuwandi,
>
> On Tue, Mar 14, 2017 at 1:54 PM, Nuwandi Wickramasinghe > wrote:
>
>>
>>
>> On Tue, Mar 14, 2017 at 12:42 PM, Thanuja Jayasinghe
>> wrote:
>>
>>> Hi Gayan,
>>>
On Sun, Mar 12, 2017 at 7:44 AM, Gayan Gunawardana wrote:
> Hi All,
>
> We are in the process of implementing password history validation feature
> for IS 6.0.0. Architecture of this feature was previously discussed in [1]
> by Isura for IS 5.3.0. We plan to follow same
On Thu, Mar 16, 2017 at 8:50 AM, Pushpalanka Jayawardhana
wrote:
>
>
> On Thu, Mar 16, 2017 at 8:46 AM, Pushpalanka Jayawardhana
> wrote:
>
>> Hi All,
>>
>> I am working on implementing 'add group' and 'update group' UIs for IS
>> 6.0.0 as per the wire-frames [1]
On Thu, Mar 16, 2017 at 9:39 AM, Gayan Gunawardana wrote:
>
> On Wed, Mar 15, 2017 at 10:19 AM, Imesh Gunaratne wrote:
>>
>>
>> ​Would you mind explaining the purpose of the field SALT_VALUE?
>>
>
> In order to compare user given password with stored password
13 matches
Mail list logo