[TYPO3-hci] BE vs FE

[Bernhard Kraft]

Waldemar Kornewald wrote:
> Hi,

Hello,

> Why is there a separation between frontend and backend users? Can't
> there just be a flag telling whether a user gets access to the
> backend? Everyone should get access to the frontend. We want users to
> register themselves to get access to additional services. For example,
> we use Trac for bug-tracking and we want single-sign-on, so our CMS
> should manage the user accounts. Or we want to restrict who can access
> certain pages. In that case, our backend users must browse the
> frontend.

This separation is there because next to editing content and creating pages
there are a lot more tasks you can do within an CMS. You can create configuration
which defines layout and behaviour of your site (TypoScript templates, Install
tool), you have many modules which allow you to view information and statistics
about your pages (Web>Info, Web>Template, Web>List). These are all "views" fo the
data forming the page in the FE.

It would be hard to add markers for every little itchy icon you need each time you
implement a new website and have a new FE template. Short: I do not want to design
my backend each time so it fit's into the Backend.

So TYPO3 made a in my opinion clever way: It had the Backend in which users could
do all stuff which is necessary within an CMS even like doing LDAP queries and other
stuff.
When a user is just a simple Editor you can configure TYPO3 to behave in such a way
that it directs the user to the FE when logged in and you can have FE editing enabled
which will mostly look like what you are looking for.

I have my own website set up in such a way that you get into the FE when logging in
into the BE (there is a select box which allows you to get into the BE directly):
http://think-open.at/typo3/index.php

And FE editing works quite well.

> I don't really get what the advantage of this separation is. It makes
> everything more complicated, but for what reason? Security? Add a
> simple flag (other CMSes already do this). What else?

If you mean why BE and FE user records are separated: That's an not so easy question.

Probably one reason could be this:

mysql_query() in php allows only a SINGLE statement to be executed ...

there are many extension programmers which do not know about SQL-injections and do not
properly escape values which are taken from GET or POST vars ...

so when there would exist a table febe_users compared to fe_users and be_users currently and
it would have a flag "is_beuser" and you would have an extension with a statement like:

$query = 'UPDATE febe_users SET firstname=\''.$_GET['firstname'].'\' WHERE uid='.$userid;

and some malicious FE-user would post:
---
MySuperFirstname', is_beuser=1
---

then he could easily become a BE user.

SQL gives natural protection against cross-table injections because the order of an UPDATE statement
is

UPDATE table SET value WHERE clause;

as "value" and "clause" (which mostly get filled with GET vars) come after the "table" value it is
hard to do something to a differnt table than which was intended - putting them in a common table
would make typo3 attackable by every badly programmed extension which handles FE users.


> This is probably only for 5.0:
> I think that we should finally get rid of this "backend" concept. AJAX
> makes this possible. Backends are more difficult to understand. What
> speaks against only having a frontend and showing simple "Edit",
> "Items", and "Admin" buttons in a simple bar at the top of every web
> page? Instead of the current scheme where your page consists of
> individual "segments" everything could become WYSIWYG-based. You could
> add forms and plugins right into the editor and configure them
> visually. Pages should become the central concept.

For me TypoScript templates are the central concept :)

Pages are just plain containers ... you can't switch any behaviour using
them - except creating hierachial structures ... the real magic happens in
TypoScript - believe me :)


> I understand that a page tree is a nice abstraction, but manipulating
> your site in-place is even better because there is no need to abstract
> anything. 

Again: See FE-Editing topics.


> Also, the current "items" concept (page list-view) is nice,
> but isn't normally a plugin needed to store items?In many cases it's
> probably better to allow plugins to add special actions to the website
> (when logged-in) and let plugins manage items. For example the news
> plugin could add a "manage news" button and take care of all news
> items. Where this data is actually stored should not be exposed to the
> user, but you should still be able to say that your news plugin should
> use the same data store as the news plugin on some other page (so you
> can have a news summary on the front page and a separate archive
> page).

Do you mean that every extension should be able to add it's own buttons to
the page-module (or the FE in your case) - I hope you do not expect that
every extension brings it's own listing modules for records it uses with
it ... this would be a lot of redundancy.


> Where do you collect your ideas for R4.5? We'll give R4 another try
> and I might have a few more suggestions after having used it a little
> bit and I don't want to repeat old suggestions.

I find your ideas quite interesting but I think the BE should stay a major part
of TYPO3 - pherhaps more attention should be brought to FE editing and it should be
improved in some ways to make it more adoptable to each specific situation (it had to
change some parts of the core for myself to get it working like I wanted to :( )



greets,
Bernhard
-- 
----------------------------------------------------------------------
"Freiheit ist immer auch die Freiheit des Andersdenkenden"
Rosa Luxemburg, 1871 - 1919
----------------------------------------------------------------------
[[ http://think-open.at | Open source company ]]