Integrated Security in a Forms asp.net App

Hi
We have a problem which I can see has been encountered by others in the past.
However, even after reading many threads on this subject it is not entirely
clear what thesolution is. I would like advice on how best to proceed.
We have an asp.net application which uses Forms authentication. Some pages
have frames which contain RS reports. The reports are called by URL. It
works great except for the security...
The application is to be used by several hundred users from outside our
organisation. The reports used within the application will also be accessed
by users on our own domain via report manager.
We have SQL Server 2000 standard edition.
I have read that I cannot configure for forms authentication because we do
not have SQL Enterprise edition. It seems that this would mess up our
authentication for internal users anyway. If I configure Report Server for
anonymous access I lose control over who sees what within our company & the
world at large can get at the reports if they figure out the URL.
What are my options for a workable integrated security solution?
Thanks
WayneWe recently had the same type of requirements. We did have to move to
Enterprise and additionally, we had to create a custom security
extension (similiar to a custom reporting extension) to handle our
special needs. Microsoft may have some examples of doing this.
This was the only solution we found.
Ken Foust|||Thanks for the reply Ken.
I've seen some examples of custom extensions, I was hoping I could avoid it
as it looks difficult & time consuming to set up. I may have to avoid it
anyway as I'm not convinced I will get approval for an upgrade to Enterprise
edition. If you are using forms authentication now, how has this affected
usage of internal reports? I've seen someone tout the idea of having
separate Forms & Windows security Report Servers, did you try this perhaps?
What a shame that RS does not cater for this common scenario straight out of
the box.
Thanks
Wayne
ken_foust@.hotmail.com wrote:
>We recently had the same type of requirements. We did have to move to
>Enterprise and additionally, we had to create a custom security
>extension (similiar to a custom reporting extension) to handle our
>special needs. Microsoft may have some examples of doing this.
>This was the only solution we found.
>Ken Foust
--
Message posted via http://www.sqlmonster.com

Integer field question

Hi
I need to create a table with an integer column that stores 2-byte
numbers in the range 0..65535, and forms part of the table's primary
key. Which data type should I pick?
I'm torn between:
(1) smallint - right size, but this is a signed type. So if a user
does a query for col > 60000, it won't work ..
(2) int - can hold number range correctly, but this is 4 bytes. I
could end up with 2 rows which are unique according to the primary
key, but having the same value for the first 2 bytes. Could fix with
an additional table constraint, but I wonder if there is a neater
way..
Can anyone recommend the best method to do this ?
thanks,
Neil
I don't think there's any simple way to do it. Int with a check constraint
to limit to numbers <= 65535 will solve it databasewise, but perhaps the
check constraint is not necessary if the middle-tier or GUI limits input to
2 bytes anyway?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
|||On 3 Mar, 09:39, "Paul Ibison" <Paul.Ibi...@.Pygmalion.Com> wrote:
> I don't think there's any simple way to do it. Int with a check constraint
> to limit to numbers <= 65535 will solve it databasewise, but perhaps the
> check constraint is not necessary if the middle-tier or GUI limits input to
> 2 bytes anyway?
> Cheers,
> Paul Ibison SQL Server MVP,www.replicationanswers.com
OK, thanks for the answer. Yes, the GUI will validate user input.
I will go for the "int" option.

Integer field question

Hi
I need to create a table with an integer column that stores 2-byte
numbers in the range 0..65535, and forms part of the table's primary
key. Which data type should I pick?
I'm torn between:
(1) smallint - right size, but this is a signed type. So if a user
does a query for col > 60000, it won't work ..
(2) int - can hold number range correctly, but this is 4 bytes. I
could end up with 2 rows which are unique according to the primary
key, but having the same value for the first 2 bytes. Could fix with
an additional table constraint, but I wonder if there is a neater
way..
Can anyone recommend the best method to do this ?
thanks,
NeilI don't think there's any simple way to do it. Int with a check constraint
to limit to numbers <= 65535 will solve it databasewise, but perhaps the
check constraint is not necessary if the middle-tier or GUI limits input to
2 bytes anyway?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com|||On 3 Mar, 09:39, "Paul Ibison" <Paul.Ibi...@.Pygmalion.Com> wrote:
> I don't think there's any simple way to do it. Int with a check constraint
> to limit to numbers <= 65535 will solve it databasewise, but perhaps the
> check constraint is not necessary if the middle-tier or GUI limits input t
o
> 2 bytes anyway?
> Cheers,
> Paul Ibison SQL Server MVP,www.replicationanswers.com
OK, thanks for the answer. Yes, the GUI will validate user input.
I will go for the "int" option.

Integer field question

Hi
I need to create a table with an integer column that stores 2-byte
numbers in the range 0..65535, and forms part of the table's primary
key. Which data type should I pick?
I'm torn between:
(1) smallint - right size, but this is a signed type. So if a user
does a query for col > 60000, it won't work ..
(2) int - can hold number range correctly, but this is 4 bytes. I
could end up with 2 rows which are unique according to the primary
key, but having the same value for the first 2 bytes. Could fix with
an additional table constraint, but I wonder if there is a neater
way..
Can anyone recommend the best method to do this ?
thanks,
NeilI don't think there's any simple way to do it. Int with a check constraint
to limit to numbers <= 65535 will solve it databasewise, but perhaps the
check constraint is not necessary if the middle-tier or GUI limits input to
2 bytes anyway?
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com|||On 3 Mar, 09:39, "Paul Ibison" <Paul.Ibi...@.Pygmalion.Com> wrote:
> I don't think there's any simple way to do it. Int with a check constraint
> to limit to numbers <= 65535 will solve it databasewise, but perhaps the
> check constraint is not necessary if the middle-tier or GUI limits input to
> 2 bytes anyway?
> Cheers,
> Paul Ibison SQL Server MVP,www.replicationanswers.com
OK, thanks for the answer. Yes, the GUI will validate user input.
I will go for the "int" option.