Hi Dilini, After adding the secondary userstore, you can find the config file related to that in *repository/deployment/server/userstores/* location. Although you have not added the regex parameters when you created the userstore from the admin service, I believe it should have added some default regex there. You need to check the following two properties in the file.
*PasswordJavaRegExPasswordJavaScriptRegEx* You can find more information on the password pattern validation from [1]. [1] http://tharindue.blogspot.com/2016/08/user-password-pattern-regex-front-end.html Thanks, TharinduE On Wed, Dec 20, 2017 at 11:46 AM, Godwin Shrimal <[email protected]> wrote: > Hi Dilini, > > Please see my comments. > > > I think it makes sense to populate additional parameters in UI when adding >>>> user store from the management console. >>>> >>> Yes, this is handled correctly from the management console side as >>>> expected. >>>> >>>> >>>>> Yeah, when adding user store via admin services its bit hard to add >>>>> those number of optional parameters. So I propose following solutions. >>>>> >>>>> 1. Improve our documentation and describe required optional parameters >>>>> and add a sample request with optional parameters >>>>> >>>> In this case, every time the optional properties are changed the doc >>>> needs to be updated and the developer needs to update the request too. >>>> >>> I don't think optional parameters are changing frequently, it is >>> something changing rearely when we need to introudce some feature to >>> perticluar user store. And if optional parameters added newly, existing >>> request should work as expected without breaking and not MUST to add that >>> parameters to request. >>> >> But, in this case it is a must to add the optional parameters in the >> request which is wrong. This hinders the usability aspect from the user >> perspective. So, IMO we should document the full request as well as handle >> it as per solution 2. >> > > As an API its not wrong not to send optional parameters, But yes. Its not > working as expected if we not send them. Yes, we need to fully document the > request with optional parameters as suggested in solution1 as an imidiate > step. We may need implement the solution 2 in future. Lets wait and see the > feedback from IAM team. > > > Thanks > Godwin > > > >> >>> >>>>> 2. Change backend to add default parameters (same as what we do in UI) >>>>> if user is not sending additional parameters in request >>>>> >>>> +1 for this solution. Here, the developer does not need to worry about >>>> the 100 odd optional parameters at all. If he needs to change few >>>> parameters, he can change only the required ones. >>>> >>>>> >>>>> >>>>> Thanks >>>>> Godwin >>>>> >>>>> On Wed, Dec 20, 2017 at 5:00 PM, Dilini Gunatilake <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi IAM Team, >>>>>> >>>>>> I need to create a JDBC secondary user store via admin services and I >>>>>> configured only the mandatory parameters and sent the request. The >>>>>> request >>>>>> was successful and the user store was created. However, when I tried to >>>>>> add >>>>>> a user to that user store, it says the password length is invalid and did >>>>>> not let me create a user. >>>>>> >>>>>> Request: >>>>>> >>>>>> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"; >>>>>> xmlns:xsd="http://org.apache.axis2/xsd"; >>>>>> xmlns:xsd1="http://dto.configuration.store.user.identity.carbon.wso2.org/xsd";> >>>>>> <soap:Header/> >>>>>> <soap:Body> >>>>>> <xsd:addUserStore> >>>>>> <!--Optional:--> >>>>>> <xsd:userStoreDTO> >>>>>> <!--Optional:--> >>>>>> >>>>>> <xsd1:className>org.wso2.carbon.user.core.jdbc.JDBCUserStoreManager</xsd1:className> >>>>>> <!--Optional:--> >>>>>> <xsd1:description>created with admin >>>>>> services</xsd1:description> >>>>>> <!--Optional:--> >>>>>> <xsd1:disabled>false</xsd1:disabled> >>>>>> <!--Optional:--> >>>>>> >>>>>> <xsd1:domainId>PRIMARY-JDBC780-ATTRIBUTE-STORE</xsd1:domainId> >>>>>> <!--Zero or more repetitions:--> >>>>>> <xsd1:properties> >>>>>> <xsd1:name>url</xsd1:name> >>>>>> >>>>>> <xsd1:value>jdbc:mysql://localhost:3306/is520user</xsd1:value> >>>>>> </xsd1:properties> >>>>>> <xsd1:properties> >>>>>> <xsd1:name>userName</xsd1:name> >>>>>> <xsd1:value>wso2carbonxxx</xsd1:value> >>>>>> </xsd1:properties> >>>>>> <xsd1:properties> >>>>>> <xsd1:name>password</xsd1:name> >>>>>> <xsd1:value>wso2carbonxxx</xsd1:value> >>>>>> </xsd1:properties> >>>>>> <xsd1:properties> >>>>>> <xsd1:name>driverName</xsd1:name> >>>>>> <xsd1:value>com.mysql.jdbc.Driver</xsd1:value> >>>>>> </xsd1:properties> >>>>>> <xsd1:properties> >>>>>> <xsd1:name>CountRetrieverClass</xsd1:name> >>>>>> >>>>>> <xsd1:value>org.wso2.carbon.identity.user.store.count.jdbc.JDBCUserStoreCountRetriever</xsd1:value> >>>>>> </xsd1:properties> >>>>>> </xsd:userStoreDTO> >>>>>> </xsd:addUserStore> >>>>>> </soap:Body> >>>>>> </soap:Envelope> >>>>>> >>>>>> >>>>>> This may be because I haven't configured the optional parameters such >>>>>> as username/password regex etc. in the request. But, IMO the request >>>>>> should >>>>>> work successfully with only mandatory parameters. >>>>>> >>>>>> If I do the same via management console, the additional parameters >>>>>> will be populated in the UI and saved in the xml when we save the >>>>>> configuration. >>>>>> >>>>>> If a developer needs to create a user store via admin services, how >>>>>> can the developer achieve this? If the developer needs to configure >>>>>> optional parameters, there are around 100 parameters. What are the must >>>>>> have additional parameters the user needs to configure or what is the >>>>>> best >>>>>> way to handle this? >>>>>> >>>>>> Thanks, >>>>>> Dilini >>>>>> >>>>>> -- >>>>>> >>>>>> *Dilini GunatilakeSoftware Engineer - QA Team* >>>>>> Mobile : +94771162518 <+94%2077%20116%202518> >>>>>> [email protected] >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Godwin Amila Shrimal* >>>>> Associate Technical Lead >>>>> WSO2 Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> mobile: *+94772264165* >>>>> linkedin: *https://www.linkedin.com/in/godwin-amila-2ba26844/ >>>>> <https://www.linkedin.com/in/godwin-amila-2ba26844/>* >>>>> twitter: https://twitter.com/godwinamila >>>>> <http://wso2.com/signature> >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Dilini GunatilakeSoftware Engineer - QA Team* >>>> Mobile : +94771162518 <+94%2077%20116%202518> >>>> [email protected] >>>> >>>> >>>> >>> >>> >>> -- >>> *Godwin Amila Shrimal* >>> Associate Technical Lead >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: *+94772264165* >>> linkedin: *https://www.linkedin.com/in/godwin-amila-2ba26844/ >>> <https://www.linkedin.com/in/godwin-amila-2ba26844/>* >>> twitter: https://twitter.com/godwinamila >>> <http://wso2.com/signature> >>> >> >> >> >> -- >> >> *Dilini GunatilakeSoftware Engineer - QA Team* >> Mobile : +94771162518 <+94%2077%20116%202518> >> [email protected] >> >> >> > > > -- > *Godwin Amila Shrimal* > Associate Technical Lead > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: *+94772264165* > linkedin: *https://www.linkedin.com/in/godwin-amila-2ba26844/ > <https://www.linkedin.com/in/godwin-amila-2ba26844/>* > twitter: https://twitter.com/godwinamila > <http://wso2.com/signature> > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Tharindu Edirisinghe Senior Software Engineer | WSO2 Inc Platform Security Team Blog : http://tharindue.blogspot.com mobile : +94 775181586
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
