Re: Selecting text 'broken' in Chrome

2016-12-01 Thread Martin Grigorov 
On Thu, Dec 1, 2016 at 8:35 AM, Dan Haywood 
wrote:

> It would seem this new behaviour in Chrome and also Firefox - probably
> making the browser more compliant with some specific - could cause issues
> for more many more Wicket apps than just Isis.
>
> Does Wicket have the notion of readonly input elements rather than
> disabled,  that we could use instead?
>

Nope!
The only "hook"
is org.apache.wicket.markup.html.form.FormComponent#onDisabled() that
actually sets "disabled" attribute. But it is not really easy to change its
behavior globally (unless you use AOP or bytecode rewrite).
Please start a thread at Wicket mailing lists. Maybe someone else will have
a better idea how to accomplish this.


>
> Dan
>
> On Thu, 1 Dec 2016, 07:02 Martin Grigorov,  wrote:
>
> > I've played a bit with disabled input and indeed it is not possible to
> > select the text inside it.
> > Also http://getbootstrap.com/css/#forms-control-disabled (the first
> > caveau)
> > says "disables all keyboard and mouse interactions".
> >
> > Wicket sets "disabled" on FormComponents when they are "disabled in
> > hierarchy", so it might be more complex than just replacing
> > formComponent.setEnabled(false) with AttributeModifier.
> >
> > Another way to solve this is to use JS that onDomReady replaces all
> > "disabled" attributes with "readonly" and on form submit reverse this
> > operation.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Wed, Nov 30, 2016 at 2:54 PM, Dan Haywood <
> d...@haywood-associates.co.uk
> > >
> > wrote:
> >
> > > If Martin's suggestion of using CSS doesn't sort the issue, then I
> guess
> > > the fix will need to be a little deeper perhaps using some other
> > Wicket
> > > API other than setDisabled(...).  Maybe something like using an
> > > AttributeModifier to put the "readOnly" attribute on instead, cf
> > > http://stackoverflow.com/a/10282380/56880
> > >
> > > On Wed, 30 Nov 2016 at 13:51 Erik de Hair  wrote:
> > >
> > > >
> > > > On 11/30/2016 01:22 PM, Dan Haywood wrote:
> > > > > oops.  I meant https://issues.apache.org/jira/browse/ISIS-1547
> > > >
> > > > Thanks Dan
> > > >
> > > > >
> > > > >
> > > > > On Wed, 30 Nov 2016 at 12:20 Dan Haywood <
> > d...@haywood-associates.co.uk
> > > >
> > > > > wrote:
> > > > >
> > > > >> Thanks both.  I've created
> > > > https://issues.apache.org/jira/browse/ISIS-1546
> > > > >>
> > > > >>
> > > > >> On Wed, 30 Nov 2016 at 11:35 Martin Grigorov <
> mgrigo...@apache.org>
> > > > wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I guess the "disabled" attribute comes from Wicket.
> > > > >> If a FormComponent is setEnabled(false) then Wicket will set this
> > > > attribute
> > > > >> to the HTML form element (input. textarea, etc.).
> > > > >> IMO the correct solution is to override the CSS rule that disables
> > the
> > > > >> selection of the text.
> > > > >>
> > > > >> Play with
> > > > >>
> > > > >> -webkit-user-select: none;
> > > > >>   -moz-user-select: none;
> > > > >>-ms-user-select: none;
> > > > >>user-select: none;
> > > > >>
> > > > >> Just change the value.
> > > > >>
> > > > >> Martin Grigorov
> > > > >> Wicket Training and Consulting
> > > > >> https://twitter.com/mtgrigorov
> > > > >>
> > > > >> On Wed, Nov 30, 2016 at 11:56 AM, Dan Haywood <
> > > > >> d...@haywood-associates.co.uk>
> > > > >> wrote:
> > > > >>
> > > > >>> If you are certain that using 'readonly' would do the trick, then
> > > > please
> > > > >>> raise a ticket for that.
> > > > >>> Thx
> > > > >>>
> > > > >>>
> > > > >>> On Wed, 30 Nov 2016 at 09:44 Erik de Hair 
> > wrote:
> > > > >>>
> > > >  Hi,
> > > > 
> > > >  I believe it was mentioned once in another thread that selecting
> > > text
> > > >  (and so copying) from a disabled field doesn't work in Firefox
> on
> > > >  Windows. Since a week or two it's not possible on a lot of
> Chrome
> > > >  installations of our users either, probably due to a Chrome
> > update.
> > > > >> This
> > > >  really is a big problem for our users because we share a lot of
> > > >  configuration data for internet access and telephony services
> and
> > > >  copying data makes sure they don't make mistakes while
> configuring
> > > > >> their
> > > >  systems.
> > > > 
> > > >  Would it be a problem to use the read only attribute instead of
> > the
> > > >  disabled attribute? That would be an easy fix.
> > > > 
> > > >  Anybody experiencing the same issue and having a nice solution?
> > > > 
> > > >  Erik
> > > > 
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: Issue in isis-module-security - in combination with delegateAuthenticationRealm

2016-12-01 Thread Vladimir Nišević 
Hi, understand, ok, will give a try!

Regs,Vladimir


2016-12-01 16:37 GMT+01:00 Dan Haywood :

> Yes, not a bug but a feature :-)  However, if you want to create a PR to
> make the behaviour configurable, will be very happy to review.
>
> Cheers
> Dan
>
> On Thu, 1 Dec 2016 at 15:32 Vladimir Nišević  wrote:
>
> > Hi, I am using security module in combination with our Active Directory:
> >
> >1. Roles and delegate users (without passwords) are created in Isis
> >security module
> >2. Authentication is done thru company Active Directory
> >
> >
> > I think, I've found an issue in this setup: As part of login procedure,
> if
> > the user doesn't exist in Isis security, it will be automatically created
> > as new delegate user (with Status=Disabled). This leads to potentially
> many
> > users in security module, every time when somebody e.g. mistypes the
> > username.
> >
> >
> > Here my shiro.ini
> >
> > *[main]*
> > *isisModuleSecurityRealm =
> > org.isisaddons.module.security.shiro.IsisModuleSecurityRealm*
> > *authenticationStrategy =
> >
> > org.isisaddons.module.security.shiro.AuthenticationStrategyForIsisM
> oduleSecurityRealm*
> > *securityManager.authenticator.authenticationStrategy =
> > $authenticationStrategy*
> > *securityManager.realms = $isisModuleSecurityRealm*
> > *isisModuleSecurityRealm.delegateAuthenticationRealm=$
> activeDirectoryRealm*
> > *activeDirectoryRealm =
> > org.apache.shiro.realm.activedirectory.ActiveDirectoryRealm*
> > *activeDirectoryRealm.searchBase =*
> > *activeDirectoryRealm.url = **
> >
> > I think the bug is in the class
> >
> > org.isisaddons.module.security.shiro.IsisModuleSecurityRealm
> >
> > line 48:
> > *  PrincipalForApplicationUser principal = this.lookupPrincipal(username,
> > this.hasDelegateAuthenticationRealm());*
> >
> > it should be:
> > * PrincipalForApplicationUser principal = this.lookupPrincipal(username,
> > false);*
> >
> > Or was it on purpose to auto create new delegate user on every login
> > attempt?
> >
> >
> > Regards
> > Vladimir
> >
>

Re: Issue in isis-module-security - in combination with delegateAuthenticationRealm

2016-12-01 Thread Dan Haywood 
Yes, not a bug but a feature :-)  However, if you want to create a PR to
make the behaviour configurable, will be very happy to review.

Cheers
Dan

On Thu, 1 Dec 2016 at 15:32 Vladimir Nišević  wrote:

> Hi, I am using security module in combination with our Active Directory:
>
>1. Roles and delegate users (without passwords) are created in Isis
>security module
>2. Authentication is done thru company Active Directory
>
>
> I think, I've found an issue in this setup: As part of login procedure, if
> the user doesn't exist in Isis security, it will be automatically created
> as new delegate user (with Status=Disabled). This leads to potentially many
> users in security module, every time when somebody e.g. mistypes the
> username.
>
>
> Here my shiro.ini
>
> *[main]*
> *isisModuleSecurityRealm =
> org.isisaddons.module.security.shiro.IsisModuleSecurityRealm*
> *authenticationStrategy =
>
> org.isisaddons.module.security.shiro.AuthenticationStrategyForIsisModuleSecurityRealm*
> *securityManager.authenticator.authenticationStrategy =
> $authenticationStrategy*
> *securityManager.realms = $isisModuleSecurityRealm*
> *isisModuleSecurityRealm.delegateAuthenticationRealm=$activeDirectoryRealm*
> *activeDirectoryRealm =
> org.apache.shiro.realm.activedirectory.ActiveDirectoryRealm*
> *activeDirectoryRealm.searchBase =*
> *activeDirectoryRealm.url = **
>
> I think the bug is in the class
>
> org.isisaddons.module.security.shiro.IsisModuleSecurityRealm
>
> line 48:
> *  PrincipalForApplicationUser principal = this.lookupPrincipal(username,
> this.hasDelegateAuthenticationRealm());*
>
> it should be:
> * PrincipalForApplicationUser principal = this.lookupPrincipal(username,
> false);*
>
> Or was it on purpose to auto create new delegate user on every login
> attempt?
>
>
> Regards
> Vladimir
>

Issue in isis-module-security - in combination with delegateAuthenticationRealm

2016-12-01 Thread Vladimir Nišević 
Hi, I am using security module in combination with our Active Directory:

   1. Roles and delegate users (without passwords) are created in Isis
   security module
   2. Authentication is done thru company Active Directory


I think, I've found an issue in this setup: As part of login procedure, if
the user doesn't exist in Isis security, it will be automatically created
as new delegate user (with Status=Disabled). This leads to potentially many
users in security module, every time when somebody e.g. mistypes the
username.


Here my shiro.ini

*[main]*
*isisModuleSecurityRealm =
org.isisaddons.module.security.shiro.IsisModuleSecurityRealm*
*authenticationStrategy =
org.isisaddons.module.security.shiro.AuthenticationStrategyForIsisModuleSecurityRealm*
*securityManager.authenticator.authenticationStrategy =
$authenticationStrategy*
*securityManager.realms = $isisModuleSecurityRealm*
*isisModuleSecurityRealm.delegateAuthenticationRealm=$activeDirectoryRealm*
*activeDirectoryRealm =
org.apache.shiro.realm.activedirectory.ActiveDirectoryRealm*
*activeDirectoryRealm.searchBase =*
*activeDirectoryRealm.url = **

I think the bug is in the class

org.isisaddons.module.security.shiro.IsisModuleSecurityRealm

line 48:
*  PrincipalForApplicationUser principal = this.lookupPrincipal(username,
this.hasDelegateAuthenticationRealm());*

it should be:
* PrincipalForApplicationUser principal = this.lookupPrincipal(username,
false);*

Or was it on purpose to auto create new delegate user on every login
attempt?


Regards
Vladimir