Controlling Access To An Ill-Behaved Web Resource

[Bruce Ide <fl...@gmail.com>]

I have to test a web resource that has a "feature" of only allowing one
log-in at a time. If someone else logs in with the same user ID, the first
session will get kicked out.

Can't think of a good way to do this in jmeter, since any number of tests
could access the resource. So I rolled a quick and dirty proof of concept
webapp to hide the actual resource behind a mutex semaphore. It uses Ruby,
Sinatra and haml to render a form. If you're interested in the code, you can
find it at
https://github.com/FlyingRhenquest/WebMutex.

It's not very pretty but initial testing looks promising. I'll have to throw
together a jmeter test to exercise it in the morning.

-- 
Bruce Ide
FlyingRhenquest@gmail.com

Re: Controlling Access To An Ill-Behaved Web Resource

[sebb <se...@gmail.com>]

On 13 June 2011 21:43, Bruce Ide <fl...@gmail.com> wrote:
> Yeah I considered that. I'd have to make one per test for that to work. We
> currently have about 40 tests, and would have to create another new admin
> user for each test.

Why?

Just run the tests in sequence, rather than in parallel.

> Although there's not a limit on the number of admin
> users in the system (Just not the same one,) managing those users would be
> more work than writing a webapp to limit access to the system.
>
> Though now that I think about it, having 40 separate admin users running in
> the system at the same time might uncover other problems, so perhaps I
> should reconsider, after all!

Indeed.

>
> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Re: Controlling Access To An Ill-Behaved Web Resource

[Bruce Ide <fl...@gmail.com>]

Yeah I considered that. I'd have to make one per test for that to work. We
currently have about 40 tests, and would have to create another new admin
user for each test. Although there's not a limit on the number of admin
users in the system (Just not the same one,) managing those users would be
more work than writing a webapp to limit access to the system.

Though now that I think about it, having 40 separate admin users running in
the system at the same time might uncover other problems, so perhaps I
should reconsider, after all!

-- 
Bruce Ide
FlyingRhenquest@gmail.com

Re: Controlling Access To An Ill-Behaved Web Resource

[Deepak Shetty <sh...@gmail.com>]

Hi
how many admin users do you normally have? on test environments we usually
reset all passwords to a known value and then you can just have the first
step query for a list of administrative users so that each thread gets its
unique admin

regards
deepak

On Mon, Jun 13, 2011 at 11:23 AM, Bruce Ide <fl...@gmail.com>wrote:

> Upon reflection, the cause of the problem is really more process than
> anything else. This feature was allowed without adequate review and is now
> causing problems with testing. Jmeter might not be able to fix that, but
> testing with it did expose a process problem!
>
> Probably the most correct solution would be to modify the application to
> print an error that the user is already logged in. Jmeter could detect that
> with a XPath or Regex postprocessor and retry until the system allows it to
> log in. We'll see if the intersection between ideal and real world allows
> for that!
>
> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

Re: Controlling Access To An Ill-Behaved Web Resource

[sebb <se...@gmail.com>]

On 13 June 2011 19:23, Bruce Ide <fl...@gmail.com> wrote:
> Upon reflection, the cause of the problem is really more process than
> anything else. This feature was allowed without adequate review and is now
> causing problems with testing. Jmeter might not be able to fix that, but
> testing with it did expose a process problem!
>
> Probably the most correct solution would be to modify the application to
> print an error that the user is already logged in.

Yes, that would be fairer. First come, first served.

Alternatively allow multiple concurrent logins with the same id.

> Jmeter could detect that
> with a XPath or Regex postprocessor and retry until the system allows it to
> log in.

Yes.

But is that how the application is supposed to be used?

Are there really going to be multiple users with the same login?

If so, then it's going to be tricky to manage when someone is no
longer allowed access - all existing users will have to be given the
new password.

Apart from the problems of tracking who is actually using the system.

> We'll see if the intersection between ideal and real world allows
> for that!

If there are multiple different admin logins, then you can use JMeter
to test these in parallel.

> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Re: Controlling Access To An Ill-Behaved Web Resource

[Bruce Ide <fl...@gmail.com>]

Upon reflection, the cause of the problem is really more process than
anything else. This feature was allowed without adequate review and is now
causing problems with testing. Jmeter might not be able to fix that, but
testing with it did expose a process problem!

Probably the most correct solution would be to modify the application to
print an error that the user is already logged in. Jmeter could detect that
with a XPath or Regex postprocessor and retry until the system allows it to
log in. We'll see if the intersection between ideal and real world allows
for that!

-- 
Bruce Ide
FlyingRhenquest@gmail.com

Re: Controlling Access To An Ill-Behaved Web Resource

[sebb <se...@gmail.com>]

On 13 June 2011 15:31, Bruce Ide <fl...@gmail.com> wrote:
> Well in this case one jmeter jmx file represents a single test which we have
> defined. We kick them all off from a Hudson server.
>
> I could create 40 different administrative users to run the tests
> simultaneously and have actually considered doing so, but the database is
> wiped periodically, so I'd have to write another test that creates all the
> administrative users, feed each test a unique administrative user ID to use
> and insure that my administrative user creation test executes prior to all
> other tests. It's about equally problematic.
>
> Or I could submit a program design change request, requesting that the
> behavior of the app be modified to allow multiple administrative logins or
> print an error message if the same admin user attempts to log in instead of
> kicking the current session out. But then I'd have to talk to developers
> (heh heh heh.)

In that case, I don't see what the WebMutex application has to do with JMeter
Seems to me you would have the same problem with any test tool.

> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Re: Controlling Access To An Ill-Behaved Web Resource

[Bruce Ide <fl...@gmail.com>]

Well in this case one jmeter jmx file represents a single test which we have
defined. We kick them all off from a Hudson server.

I could create 40 different administrative users to run the tests
simultaneously and have actually considered doing so, but the database is
wiped periodically, so I'd have to write another test that creates all the
administrative users, feed each test a unique administrative user ID to use
and insure that my administrative user creation test executes prior to all
other tests. It's about equally problematic.

Or I could submit a program design change request, requesting that the
behavior of the app be modified to allow multiple administrative logins or
print an error message if the same admin user attempts to log in instead of
kicking the current session out. But then I'd have to talk to developers
(heh heh heh.)

-- 
Bruce Ide
FlyingRhenquest@gmail.com

Re: Controlling Access To An Ill-Behaved Web Resource

[sebb <se...@gmail.com>]

On 11 June 2011 08:49, Bruce Ide <fl...@gmail.com> wrote:
> I have to test a web resource that has a "feature" of only allowing one
> log-in at a time. If someone else logs in with the same user ID, the first
> session will get kicked out.
>
> Can't think of a good way to do this in jmeter, since any number of tests
> could access the resource.

Do you really mean tests? If so, don't run multiple JMeter instances,
or ensure they use different user ids.

If you mean multiple threads can access the resource, then the same
applies - ensure each thread uses its own user ID.
This is easy to do - search the archives.

> So I rolled a quick and dirty proof of concept
> webapp to hide the actual resource behind a mutex semaphore. It uses Ruby,
> Sinatra and haml to render a form. If you're interested in the code, you can
> find it at
> https://github.com/FlyingRhenquest/WebMutex.
>
> It's not very pretty but initial testing looks promising. I'll have to throw
> together a jmeter test to exercise it in the morning.
>
> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org