Custom Rule - DuplicateUsername check

[Jason Durham]

I'm having trouble understanding how this scenario should be configured with ValidateThis.

My app uses an email address for authentication.  During registration, a custom rule will ensure that the email address is not already in use.  However, it will be possible for a user (or an elevated user) to modify this email address at a later time.  I'm unable to reuse the custom rule because it will fail each time a user's profile is edited and saved without changing the email address.  Essentially... the email address in use for the current user.

How are you guys/gals performing a duplicate username check for when you edit an existing profile?  Perhaps I could store the user's current address in a hidden form field and write a client side condition that compares the hidden field to the visible field?  Any other ideas?

Thanks,
Jason Durham

[Matt Quackenbush]

I've never worried about that sort of check on the client side. On the server side I've typically added a non-persistent "shadow field" that is populated with the same value as the real field. The custom validation method returns true (valid) if those two fields match; otherwise it performs the check based upon the value in the real field. No reason you couldn't do the same thing on the client side, though.

HTH

HAH! Just re-read your post. Yeah, that's what I'd do. :-)

--
You received this message because you are subscribed to the Google Groups "ValidateThis" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validatethis...@googlegroups.com.
To post to this group, send email to valida...@googlegroups.com.
Visit this group at http://groups.google.com/group/validatethis?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jason Durham]

Thanks Matt. I wasn't ready to give up on the client-side just yet.  I thought I could create a condition that would be evaluated as values are manipulated in a particular form field.  Here is a snippet of the clientTest portion of my condition (it's property encoded on my def file):

$("input[name='currentEmailAddress']").length > 0 && $("input[name='currentEmailAddress']").getValue() !== $("input[name='emailAddress']").getValue();

I thought this JS snippet would be evaluated before each execution of my custom rule to determine if the rule needs to run.  Is that assumption incorrect?  It appears so. The remote call runs every time I try to edit an existing email address (regardless as to the value of it or the currentEmailAddress field).

Here are the actual XML nodes...

....

<condition name="isNotCurrentEmailAddress" serverTest="1 eq 1"clientTest="$(&quot;input[name='currentEmailAddress']&quot;).length &gt; 0 &amp;&amp; $(&quot;input[name='currentEmailAddress']&quot;).getValue() !== $(&quot;input[name='emailAddress']&quot;).getValue();" />

.....

<property name="emailAddress" desc="Email Address">

<rule type="required" />

<rule type="email" failureMessage="Hey, buddy, you call that an Email Address?" />

<rule type="custom" condition="isNotCurrentEmailAddress" failureMessage="Email address already exists.">

<param name="methodName" value="isUniqueEmailAddress" />

<param name="remoteURL" value="/ColdboxProxy.cfc?method=isUniqueEmailAddress&amp;returnformat=plain" />

</rule>

</property>

....

Jason Durham

[Jason Durham]

I think I stumbled on a simpler solution.  I'll just dynamically modify the remoteURL to include the current user's PK and change my lookup to exclude the provided userID's email address from its search. 

Jason Durham

[Dan G. Switzer, II]

There's also the "context" attribute which is designed for the purpose--to only apply a validation rule in a specific situation. 

-Dan

--

You received this message because you are subscribed to the Google Groups "ValidateThis" group.
To unsubscribe from this group and stop receiving emails from it, send an email to validatethis...@googlegroups.com.
To post to this group, send email to valida...@googlegroups.com.
Visit this group at http://groups.google.com/group/validatethis?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Dan G. Switzer, II

dswi...@pengoworks.com

http://blog.pengoworks.com/

[Jason Durham]

Thanks Dan. I don't think contexts apply to this situation. I don't want to completely omit the custom rule when a user updates their email address.  Instead, I either need to detect the user has changed their email address before evaluating whether or not to run the remote validation.  Or, I need to supply an additional argument in the remoteURL so I can exclude the current user's email address during the lookup.

ie.  select 1 from Users where emailAddress = '#emailAddress#' and userID != '#currentUserID#'

In order to be able to execute that query, the remoteURL must contain the current user's ID.

So far, I've been unsuccessful either idea.  I'm currently investing creating a new CRV which allows me to supply additional parameters in the remoteURL call.

Jason Durham

[Jason Durham]

I have a working solution (at least in Chrome with ACF10). I discovered that conditions are not evaluated for custom validation types.  If fact, it appeared like conditions were only used for the required validation type.  In any event, getParameterDef in ClientRuleScripter_custom.cfc is where the value for the client-side validation JSON is built.  I modified it so that a depends property is created when a condition exists.  This is what the generated JSON looks like now:

emailAddress: 

{

• remote: 

  {

  • param: 

    {

    • url: "/ColdboxProxy.cfc?method=isUniqueEmailAddress&returnformat=plain"

    },
  • depends: "isNotCurrentEmailAddress"

  },
• required: 

  {

  • DependentInputName: "",
  • DependentInputValue: "",
  • DependentInputDesc: ""

  },
• email: true

}

Jason Durham

[Jason Durham]

Whoops.. I forgot to mention that I didn't modify ClientRuleScripter_custom.cfc.  I created a new CRV and SRV and placed them in an external location.

Jason

Jason Durham