"Salad" <salad (AT) oilandvinegar (DOT) com> wrote

Golly, I am in a good mood, so I shall not comment on the above!

Yes, the above is in fact quite correct. On the other hand, I don't think
you taken the time to realize what is involved in a web based application.

Can you find me an example of a database online and don't have to login that
was written in asp.net for example? (and, asp.net been out for years!).

Few if any business wants a system WIDE OPEN to the public without some kind
of sign up or logon process. In fact, I not found any business that is
looking to do this with their Access applications either.

Not true. You can allow and use anonymous users, but the use of that is very
limited. And, there is some licensing issues in terms of cost when you do it
this way.

You have to step back and think about the dance of the systems you need
here. What database server are you going to adopt to store your data? What
security for that database server are now going to going to use? So you mean
you throw up a web form, but the database server is going to be 100% open to
the public? Everyone can now take away your data? We see on a daily basis
all of these data thefts that are occurring on the Internet because simply
too many people not given this issue a thought.

If you don't have a secure mechanism that the database server recognizes,
how are you going to prevent each user from not seeing data you don't want
them to see? And in fact what about general web pages that you want some
users to view, and others to not view? You think you going to write code and
security into every web page you build? A good portion of those web pages
are not going to be access forms. You REALLY need to adopt some overall
secure model for your web systems, regardless of what your goal is here.

You might have 10 different applications that you're running on that system.
How are those 10 different applications going to know what security and what
person and who is accessing that information? You really do need some type
of mechanism for creating a user that all applications can adhere to. When
you start looking at SharePoint, there is a absolute truckload of other
services and things that you'll need (and want) to utilize.

For example what system do you think access uses on sharepoint for rendering
access reports? (answer: it uses SQL server reporting services). You don't
think they built a web based reporting system just for access did you?
Exactly what kind of software budgets and how big of a team do you think
they have here? However, just like a typical access appliation might use
Word or Outlook, the web is the SAME...you need other systems.

As for having to adopt sharepoint? Yes, this is a big issue. However, it not
so much different then if you write for the oracle database server, you're
certainly not gonna be able to take your application and publish it to a
site that runs that Oracle database on that server are you? And if you're
hosting provider doesn't have oracle databases, what you're writing is not
going to work is it?

And if you write your application to specifications use mySQL, that
application will not work with SQL or Oracle will it?

So the idea of a one click to publish to some system, certainly means that
you're going to have to adopt a web server with a FIXED set of standards. I
mean if you use one vendors reporting system to render and build reports,
obviously if your hosting provider does not support that particular report
writer, then your applications not gonna work is it?

You can write to the LAMP standard (linux, Apache, MySql, PHP). Of course if
you write to that standard, and your hosting provider doesn't support the
systems in LAMP, then you never be able to publish to that site? And, again,
what report writing system are you going to use here? And are you going to
be able to convince the hosting provider, or the company you doing work for
to adopt and install and set up and maintain and support that report writer?
(gee, this is starting to get a little bit complicated, isn't it?).

If you decide to adopt asp.net, then your web server (or your customers
current hosting) better be running those .net technologies. If you write to
oracle standards, then again, you need those exact systems and support on
that web server.

So what happens if they already have a website right now? And you now need
to interact with your access application? So, you suggest ANOTHER hosting
provider and now what about all of their current logons and current users
and current customer Service Systems that they have on their existing web
server?

So, now all the customers have to sign up again to use another application
with another set of users and passwords. And, who is gonna manage all the
resetting and management of all these passwords? Great, we sold a web site,
but now we spending all day resetting customers passwords, and looking up
forgotten user names. (how on earth is this kind of proposal going to save
them money?).

IN ALL OF THE ABOVE cases if just one of the technologies from the web
server from using Apache in place of IIS web server means your applications
not going to work. This is not a whole lot different then writing your
software for Foxpro, and then assuming it's going to run under ms access.

And, you better be able to tie the reporting system, the database system,
email, documents, pictures...everything into ONE security model.

So in the case of having to adopt sharepoint, there's some really great
up-sides that solves a HUGE list of issues and problems.
And, yes there also no question that the cost issue is a big issue. (that
means the company is willing to spend money
on IT...exactly the kind of customers I am looking for by the way).

Oh, by the way, that system that just lets you magically published to some
web site and not worry about users? Can you give me a example of such a
publishing system FROM ANY vendor? I mean, we had bucket loads of asp.net
developers (10 years now). Do you have a link to a nice little asp.net
application with a database and no logon?

Remember, access 2010 only been out a few months. See my other post, those
were all SharePoint web sites, and pubic facing ones at that.

And what are you going to use to control the web site content? What web
pages, what documents, what applications? Surely you don't think the
computer just runs one application like access?

The problem in the case of a web server is with many users, so you better
have a system-wide well thought out Security System in place.

You're certainly not suggesting that every single web page has a signup
process? And then every single application on the web site ALSO need some
type of signup process? Exactly how do you propose to manage this process?
How do you propose to manage the security for all that stuff? And, if they
already have a system, but you introduce another hosted system, now you have
ANOTHER big mess of user logons to deal with?

If it was easy, then find me the asp.net + database and a public facing site
without a logon then?

Sure, there is, but I can't teach you to fly in one newsgroup post.

And, there is a ton of new questions here.

The big problem is that suspect that in another year or so, everyone in this
group going to finally wake up and realize how important the WEB is.
Precious time is being wasted here for those not jumping on the WEB
bandwagon. It is SO VERY important for the future of our industry, and MORE
important for future work as a developer to get up to speed on web based
technologies.

I remembered when I started working in this wonderful industry, it was
around the time of clipper, FoxPro, dbase etc. When windows and the mouse
with a GUI came out, there was a whole big chunk of developers that simply
did not make the transitions into windows based programming (we could call
this paradigm change the transition into "event driven programming"). They
really just did not see the writing on the wall, or did not care. Or they
were not interested in going to the next new technology ways that was
hitting our industry.

I fear I'm witnessing the same thing again for web based technologies, and
all too many developers are failing to realize how significantly important
it is to start dealing with the realities of web based development. You have
to start setting time aside, and make an actual on its commitment to say
that it's important to upgrade your skill set and to start to learn how the
some these web based system work. It does not have to SharePoint, but you
better pick some horse right now, because all of the horses have left the
starting Gate.

I mean exactly what platform to you plan to learn that will let you deploy
forms, code and logic, and reports that a typical business needs? You have
to adopt something, because any of these technologies are going to take you
a good year or so to get up to speed on learning the systems. All during the
while you have to keep your regular life up and running. So, this is hard to
do but if you don't adopt some of these technologies, you're going to sorely
miss some opportunity's that are available in the marketplace right now..

I like SharePoint because it tends to allow one to take traditional classic
business processes that most access developers have worked with, and move
them towards the web over time. (unfortunately, the reality is, is I will be
using some asp.net here also).

However, what ever you choose, you have to pick something that will make you
productive like ms-access. MORE importantly has a good adoption rate by
businesses, and will THEN allow you to write software and deploy into that
marketplace.

Access is great right now, because you can build something, and deploy it to
windows desktop. So, you better come up with the same scenario for web based
systems, otherwise you could learn 4 or 5 different web based technologies,
but not be able to write an application that you can deploy and use parts of
libraries over and over to the many clients you expect to have over the
years. If every single customer in every web site and application you build
is like starting from scratch, you're not going to get anywhere in this
industry.

I try to answer some questions of the road to the web here:

http://www.members.shaw.ca/AlbertKal...web/Index.html

I again am just plain out of time, and have to stop. I could type a book of
more issues here, but the above and that link will start to answer some
questions.

Albert K.

Salad <salad (AT) oilandvinegar (DOT) com> wrote in
news:Yf2dnSbQfalmU9DRnZ2dnUVZ_jqdnZ2d (AT) earthlink (DOT) com:

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/

"David W. Fenton" <NoEmail (AT) SeeSignature (DOT) invalid> wrote


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..

"Salad" <salad (AT) oilandvinegar (DOT) com> wrote



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.

Albert D. Kallal wrote: