Prev: Access 2010 x64 problem.
Next: converting to access2003 from access97
From: David W. Fenton on 27 Jul 2010 20:00
Salad <salad(a)oilandvinegar.com> wrote in
news:Yf2dnSbQfalmU9DRnZ2dnUVZ_jqdnZ2d(a)earthlink.com:

> When I heard the phrase "publish to the web", I mistakenly thought
> I could provide a link to the database to users and they could
> come in to the site, run reports, etc.
>
> Then I learned that that user needs to be a user in the Sharepoint
> server. It made sense. Initially I figured a user was something
> like "owner", "developer". and "user". And you paid for some disk
> space on a hosting site. And the app determined what records to
> display or what forms and reports a user had based on a key they'd
> enter. Like in the login form.
>
> From what I understand now its one user, one access. So if you
> had a
> 100 customers or vendors, and you wanted to share your database
> application with them you'd need 100 user licenses. And the cost
> at a hosting site might run $7-8 dollars per user/per month. The
> cost would run about $8,400 to $9,600 a year. And that would not
> include any company staff access to the app or the monthly cost of
> hosting.

Have you ever developed a traditional database-driven website that
wasn't read-only? Have you even developed one that *was* read-only?

For a read-only website, you don't have the users log on -- your PHP
or ASP scripts use a read-only logon to retrieve data that is
displayed for the users.

If you need to track users, then there are a number of ways to do
that.

Your initial description of how Sharepoint works with 100s of
licenses required is if you use standard Active Directory
authentication via Sharepoint. On an Intranet, or inside a company
LAN or WAN, that will be just fine, because people are already
likely authenticating against your domain controller, so it's not
more expensive for you to use AD security for your internal web
users.

But from outside that walled garden, you don't have full access to
AD, and the users are not going to be pre-authorized. From what
Albert has said, it is possible for Sharepoint to authenticate in
the manner, but as you say, it's not practical.

Thus, you need some other authentication method.

This is actually the question I asked Albert just a few days ago,
and he answered it by saying that the Sharepoint server has its own
set of web-appropriate authentication services, including session
management and so forth.

If you've never developed for the web, this is likely to make little
sense. And that, I think, is the key part of the puzzle that you're
missing -- you don't actually appreciate how things have
traditionally been done on websites. In fact, outside Sharepoint,
it's generally a roll-your-own world, and as everyone knows, that's
a recipe for less-than-stellar security.

The usual way is to have a single read/write user that the web
server uses to interact with the database, but to have the user
logon layer in the HTML application be the "keeper of the keys" to
the scripts that can edit the database. You have to be authorized
through that front-end layer or you can't run the scripts that can
write to the database.

Is this subject to implementation error and thus vulnerable?

Yes.

Does this mean everyone is constantly re-inventing the wheel?

Yes.

Does it mean that you have to maintain multiple data tables of users
and user permissions in your web applications' databases?

Generally, yes.

From what Albert has said, I gather that What Sharepoint provides is
a standard user authentication layer that you can use in all your
Sharepoint-hosted apps so that:

1. you're using code developed by MS, which is much less likely to
have holes in it than any code you can write yourself.

2. you don't have to write any code for user authentication, you
just have to use the interfaces MS provides to Sharepoint's
authentication services.

3. you don't have to track your users within each web-based app --
instead, you can have all your Sharepoint-based apps utilize the
same user database.

Now, of course, I may be making wrong assumptions here because I'm
going by what Albert has said and from what I've read. The key point
is that while this may seem like a step back from Windows
authentication in Access apps that use a SQL Server back end, it's a
huge step forward in ease of use, security and maintenance for
WEB-BASED DATABASE APPLICATIONS.

Albert will chime in and say where I've got things wrong. I hope
there's not been too much that's off base.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
From: Salad on 27 Jul 2010 20:49
David W. Fenton wrote:

> Salad <salad(a)oilandvinegar.com> wrote in
> news:Yf2dnSbQfalmU9DRnZ2dnUVZ_jqdnZ2d(a)earthlink.com:
>
>
>>When I heard the phrase "publish to the web", I mistakenly thought
>>I could provide a link to the database to users and they could
>>come in to the site, run reports, etc.
>>
>>Then I learned that that user needs to be a user in the Sharepoint
>>server. It made sense. Initially I figured a user was something
>>like "owner", "developer". and "user". And you paid for some disk
>>space on a hosting site. And the app determined what records to
>>display or what forms and reports a user had based on a key they'd
>>enter. Like in the login form.
>>
>> From what I understand now its one user, one access. So if you
>> had a
>>100 customers or vendors, and you wanted to share your database
>>application with them you'd need 100 user licenses. And the cost
>>at a hosting site might run $7-8 dollars per user/per month. The
>>cost would run about $8,400 to $9,600 a year. And that would not
>>include any company staff access to the app or the monthly cost of
>>hosting.
>
>
> Have you ever developed a traditional database-driven website that
> wasn't read-only? Have you even developed one that *was* read-only?
>
> For a read-only website, you don't have the users log on -- your PHP
> or ASP scripts use a read-only logon to retrieve data that is
> displayed for the users.
>
> If you need to track users, then there are a number of ways to do
> that.
>
> Your initial description of how Sharepoint works with 100s of
> licenses required is if you use standard Active Directory
> authentication via Sharepoint. On an Intranet, or inside a company
> LAN or WAN, that will be just fine, because people are already
> likely authenticating against your domain controller, so it's not
> more expensive for you to use AD security for your internal web
> users.
>
> But from outside that walled garden, you don't have full access to
> AD, and the users are not going to be pre-authorized. From what
> Albert has said, it is possible for Sharepoint to authenticate in
> the manner, but as you say, it's not practical.
>
> Thus, you need some other authentication method.
>
> This is actually the question I asked Albert just a few days ago,
> and he answered it by saying that the Sharepoint server has its own
> set of web-appropriate authentication services, including session
> management and so forth.
>
> If you've never developed for the web, this is likely to make little
> sense. And that, I think, is the key part of the puzzle that you're
> missing -- you don't actually appreciate how things have
> traditionally been done on websites. In fact, outside Sharepoint,
> it's generally a roll-your-own world, and as everyone knows, that's
> a recipe for less-than-stellar security.
>
> The usual way is to have a single read/write user that the web
> server uses to interact with the database, but to have the user
> logon layer in the HTML application be the "keeper of the keys" to
> the scripts that can edit the database. You have to be authorized
> through that front-end layer or you can't run the scripts that can
> write to the database.
>
> Is this subject to implementation error and thus vulnerable?
>
> Yes.
>
> Does this mean everyone is constantly re-inventing the wheel?
>
> Yes.
>
> Does it mean that you have to maintain multiple data tables of users
> and user permissions in your web applications' databases?
>
> Generally, yes.
>
> From what Albert has said, I gather that What Sharepoint provides is
> a standard user authentication layer that you can use in all your
> Sharepoint-hosted apps so that:
>
> 1. you're using code developed by MS, which is much less likely to
> have holes in it than any code you can write yourself.
>
> 2. you don't have to write any code for user authentication, you
> just have to use the interfaces MS provides to Sharepoint's
> authentication services.
>
> 3. you don't have to track your users within each web-based app --
> instead, you can have all your Sharepoint-based apps utilize the
> same user database.
>
> Now, of course, I may be making wrong assumptions here because I'm
> going by what Albert has said and from what I've read. The key point
> is that while this may seem like a step back from Windows
> authentication in Access apps that use a SQL Server back end, it's a
> huge step forward in ease of use, security and maintenance for
> WEB-BASED DATABASE APPLICATIONS.
>
> Albert will chime in and say where I've got things wrong. I hope
> there's not been too much that's off base.
>
Maybe, maybe not. I'm was asking a question on cost.

If a company doesn't have Sharepoint and wants an Access app on the web,
it appears one must use hosting. I'm sure there's a cost having your
own site, BTW. In hosting there is a per-user fee to that. The hosting
company I talked to the range per user, excluding sharepoint hosting
space, is between 7-8 dollars...per month.

If one had 100 active clients and you wanted them to view reports on the
ir stuff...say the status of there order...then if I understand it
correctly you need to add them on as a user...or about 90/year per user.
If a company had a lot of users that could run into some serious
cash. You start adding in your staff and the cost is heading
upward...quickly.

I can understand having data entry people scatterred across the US,
working 8 hours a day, and it being cost effective. Paying $7.50 a
month for something that may be used once a month, kind of steep.

A person can develop an app in A2010. Convert to an MDE. Distribute
it. Cheap. Saying to the boss...and you can also spend $10,000 or more
per year so the client can see a report he/she may or may not use and
the boss might say..."send em an email with a pdf attachment.".

I asked in a forum if anybody has a sample app I could view or play
with. Not a nibble. If the person needs to cough up $8 so I can view
his app, what would be the reason? How soon is he going to recoup his
loss with me? He'd be waiting a long time.

I can understand the need for security. I don't see the reasoning of
having an item prices itself out the market. Microsoft gains. The
hoster gains. Does the company I develop for gain as well?




From: Albert D. Kallal on 28 Jul 2010 11:08

"David W. Fenton" <NoEmail(a)SeeSignature.invalid> wrote in message
news:Xns9DC2C741088E0f99a49ed1d0c49c5bbb2(a)74.209.136.97...

> Now, of course, I may be making wrong assumptions here because I'm
> going by what Albert has said and from what I've read. The key point
> is that while this may seem like a step back from Windows
> authentication in Access apps that use a SQL Server back end, it's a
> huge step forward in ease of use, security and maintenance for
> WEB-BASED DATABASE APPLICATIONS.
>
> Albert will chime in and say where I've got things wrong. I hope
> there's not been too much that's off base.
>

Off to work...but, you are 100% on the money here. You have this correct.

The point about not having to "roll my own security" is a big deal, and in
fact the more I think about this, the more I like SharePoint.

For sure some filtering and restrictions stuff is going to be part of the
application design, but least the big picture part is already built.

As mentioned, of these two authentication methods, you can build "self
serve" web sites in which people sign up. The rest of the security works the
same for either windows authenticated users (Active Directory) and the
"Forms based authentication".

However, I will say that the fact that the Access client can link to these
tables opens up some issues that will make keeping data separate from each
user more difficult. I am not finished working out the details on this and
like everyone else, this is all new to me.

For web forms, this is easy since I just base the web form on web query that
is filtered by the user name and I am done. However, if they can link to the
table, then that filter is gone. So, I still figuring out some of these
details here. There is a number of other approaches here I am looking into.

Albert k..



From: Albert D. Kallal on 28 Jul 2010 11:14
"Salad" <salad(a)oilandvinegar.com> wrote in message
news:0eqdncSAVLU849LRnZ2dnUVZ_hidnZ2d(a)earthlink.com...


> I asked in a forum if anybody has a sample app I could view or play with.

I am planning to do the above, but in place of doing that, I spending time
here answering questions!

So, yes, I do plan to let some people here play with a few access
applications. I will even let you
run the application WITHOUT having to sign up (but, I will make it read
only). And, you be able to
self sign up if you want to enter test data. I not had the time to setup
FBA logons the way I
want.

The product only been out a few months, and there is 1000's of details and
things I have to learn.

So, I will post some public links here.

It is coming soon, hang on! I am setting up the farmyard and you coming over
with a fork and knife ready to eat my food, and I not even finished growing
that food!

Albert k.





From: Salad on 28 Jul 2010 12:17
Albert D. Kallal wrote:

> "Salad" <salad(a)oilandvinegar.com> wrote in message
> news:0eqdncSAVLU849LRnZ2dnUVZ_hidnZ2d(a)earthlink.com...
>
>
>> I asked in a forum if anybody has a sample app I could view or play with.
>
>
> I am planning to do the above, but in place of doing that, I spending
> time here answering questions!
>
> So, yes, I do plan to let some people here play with a few access
> applications. I will even let you
> run the application WITHOUT having to sign up (but, I will make it read
> only). And, you be able to
> self sign up if you want to enter test data. I not had the time to
> setup FBA logons the way I
> want.
>
> The product only been out a few months, and there is 1000's of details
> and things I have to learn.
>
> So, I will post some public links here.
>
> It is coming soon, hang on! I am setting up the farmyard and you coming
> over with a fork and knife ready to eat my food, and I not even finished
> growing that food!
>
> Albert k.
>
Looking forward to it, Albert.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Access 2010 x64 problem.
Next: converting to access2003 from access97