|
Home > Archive > Macromedia Flash Server > May 2006 > Limiting users accessing app instance
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Limiting users accessing app instance
|
|
| Lumenbrite Support 2006-05-29, 4:57 pm |
| Hi Everyone,
I wanted to find out if there is a way to limit users by their IP address or
machine ID through the server XML files. I know you can set the bandwidth
ceiling per application, but this can be tedious if you have to do this cap
for every individual application. I want to prevent users from being able
to open multiple instances on one computer.
Please help,
Roman J Villarreal
Pulse Media, Inc.
Lumenbrite Training
217 North Stanton Street
El Paso, TX 79901
(915) 838-1015
(915) 838-1016
lumenbrite.com <http://www.lumenbrite.com>
________________________________________
_______
FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
| |
| Bill Sanders 2006-05-29, 4:57 pm |
| Hi Roman,
There's a Clienti.ip property. Just don't allow any dups and your job
is done.
HTH,
Bill
Go Miners!
On May 28, 2006, at 1:30 PM, Lumenbrite Support wrote:
> Hi Everyone,
>
> I wanted to find out if there is a way to limit users by their IP
> address or
> machine ID through the server XML files. I know you can set the
> bandwidth
> ceiling per application, but this can be tedious if you have to do
> this cap
> for every individual application. I want to prevent users from
> being able
> to open multiple instances on one computer.
>
> Please help,
>
>
>
> Roman J Villarreal
>
> Pulse Media, Inc.
>
> Lumenbrite Training
>
> 217 North Stanton Street
>
> El Paso, TX 79901
>
> (915) 838-1015
>
> (915) 838-1016
>
>
>
> lumenbrite.com <http://www.lumenbrite.com>
>
>
>
>
>
> ________________________________________
_______
> FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
________________________________________
_______
FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
| |
| Jayson K Hanes 2006-05-29, 4:57 pm |
| That would really be a bad way to handle things.. for 2 really big
reasons:
1) dead and/or un-garbage collected (terminated) connections.. (they'd
have to wait at least the GC interval.. and hope their connection gets
terminated)
2) users who access the application from behind a router... 1 to many
NAT... they would all be using the same public IP address.
The problem should thus be obvious..
There would have to be some other kind of server-side logic that
inspects activity to the client with a ping and then compares a count
per ip as such.
-Jayson
[vbcol=seagreen]
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org [mailto:flashcomm-
> bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Bill Sanders
> Sent: Sunday, May 28, 2006 3:12 PM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] Limiting users accessing app instance
>=20
> Hi Roman,
>=20
> There's a Clienti.ip property. Just don't allow any dups and your job
> is done.
>=20
> HTH,
> Bill
>=20
> Go Miners!
>=20
> On May 28, 2006, at 1:30 PM, Lumenbrite Support wrote:
>=20
________________________________________
_______
FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
| |
| Bill Sanders 2006-05-29, 4:57 pm |
| Jayson,
1) Hadn't thought of that, but you're right. GC would prevent re-
connection. However, on disconnect all IP addresses of leaving
clients could be removed from an array(), no?
2. Good point.
Thanks,
Bill
On May 28, 2006, at 4:02 PM, Jayson K Hanes wrote:
> That would really be a bad way to handle things.. for 2 really big
> reasons:
>
> 1) dead and/or un-garbage collected (terminated) connections.. (they'd
> have to wait at least the GC interval.. and hope their connection gets
> terminated)
> 2) users who access the application from behind a router... 1 to many
> NAT... they would all be using the same public IP address.
>
> The problem should thus be obvious..
>
> There would have to be some other kind of server-side logic that
> inspects activity to the client with a ping and then compares a count
> per ip as such.
>
> -Jayson
>
> ________________________________________
_______
> FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
bill sanders | www.sandlight.com | bloomfield, ct | 860-242-2260
________________________________________
_______
FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
| |
| Jayson K Hanes 2006-05-29, 4:57 pm |
| But that comes back to the issue of "waiting for FCS to really know a
user has disconnected".. clean disconnects are of no consequence here..
it's all about the infamous dirty disconnects that will fail here..
until the GC successfully removes them... (if ever.. lol)
Some other logic will have to be implemented behind the scenes to
satisfy such a desire..
-Jayson
[vbcol=seagreen]
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org [mailto:flashcomm-
> bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Bill Sanders
> Sent: Sunday, May 28, 2006 4:09 PM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] Limiting users accessing app instance
>=20
> Jayson,
>=20
> 1) Hadn't thought of that, but you're right. GC would prevent re-
> connection. However, on disconnect all IP addresses of leaving
> clients could be removed from an array(), no?
>=20
> 2. Good point.
>=20
> Thanks,
> Bill
>=20
> On May 28, 2006, at 4:02 PM, Jayson K Hanes wrote:
>=20
(they'd[vbcol=seagreen]
gets[vbcol=seagreen]
many[vbcol=seagreen]
count[vbcol=seagreen]
________________________________________
_______
FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
|
|
|
|
|