openerp-community team mailing list archive
-
openerp-community team
-
Mailing list archive
-
Message #04477
Re: OpenERP CMS: How is server separation implemented?
On 17 Jan 2014, at 23:10, W. Martin Borgert wrote:
> On 2014-01-17 19:37, Kurt Haselwimmer wrote:
>> Think about it for one minute - how much easier will it be for translators to translate your website into their language - now that they can see the text they are translating when they can see it in the proper context - rather than editing the content in a some file tucked away with a line like $checkout_error1="Please correct form entry".
>
> This sounds weird. Isn't everybody using gettext (or similar
> techniques) nowadays for translations?
Not if you actually want a human to translate it. Even the latest cart systems that actually have the translatable content separated properly out from everything else will have that content spread about many template files and dynamic configuration fields, none of which will show the final context in which the translated copy must appear. For example translating english into german often leads to a 20-30% increase in character count which can often mess up page layouts if you can't see the final context in which the text is going to be used at the point that you're doing the translation.
>
>> The concerns that people have over security are exactly the same as any webstore that is processing credit card information
>
> I disagree. In an ERP you have much more data than only that.
> There is a lot of data that should never, ever be on a
> publically accessible server, such as employees contract data or
> their illness times. A public web shop should only have the
> necessary data on the server.
>
> Example: A company puts a job offer on their website using the
> OE Recruitment process module. So you must have the job
> description on the public server as well as a way to upload CVs
> etc. What you definetely do not want to have on an external
> server is the internal recruitment rating process. If this
> information gets into the wrong hands, it might harm your
> company.
>
>> 1) IP range restriction for admin access.
>> 2) IP blocking once you do spot an obvious hack attempt
>> 3) Possible secondary access password for admin edits
>> 4) Ability to roll-back content to a particular date (should the worst happen.)
>
> Some rogue data center staff member might copy your PostgreSQL
> database. This is less likely inside your company, where only
> few well-known admins have access. It is best practise in
> security to have only the minimum of data on certain systems, so
> that a possible breach has the least impact.
>
> Cheers
All this discussion of security is generally healthy - especially if it can lead to productive improvements in the products rather than just a digital trail of discontent. I would suggest that openERP.com find a way to open up the discussion in a way that is non-defensive and that leads to improvement suggestions being debated publicly.
References