Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Duplicate classes. Why?


Recommended Posts

I suppose this question has been asked before, but I couldn't find an answer.

 

Is there a reason for having most of the classes must exist twice in admin and in the shop side? I know most of them are slightly different but Im not sure if this is an historical reason or there are some needs that forces this.

Link to comment
Share on other sites

Its historical reason.

:blink:
osCommerce based shop owner with minimal design and focused on background works. When the less is more.
Email managment with tracking pixel, package managment for shipping, stock management, warehouse managment with bar code reader, parcel shops management on 3000 pickup points without local store.

Link to comment
Share on other sites

Possibly it was done for security reasons, to isolate the admin side code so it could be protected by password protection (and possibly to allow SSL-controlled access on admin). However, what started out as identical code on both sides has gradually mutated into two slightly different versions. This is bad. What osC should do is have a library of common routines and classes, and copy from store catalog to admin during installation. That assumes that you can't have a file shared between the store front end (catalog) and a password-protected admin side (possibly under SSL), which may be true for many systems.

Link to comment
Share on other sites

Yes I think the same. I've seen calls from the admin side to the includes of the shop side, and that doesn't look logical nor practical.

 

I started a thread here http://www.oscommerce.com/forums/topic/399551-orders-class/ talking aboutsome inconsistences with orders class. These could be fixed by using just one class directory. And I think that matches the criteria of Harald for making the codebase lighter and remove duplicate or obsolete code.

Link to comment
Share on other sites

This would be the step by step direction of the development as you see in v3.

:blink:
osCommerce based shop owner with minimal design and focused on background works. When the less is more.
Email managment with tracking pixel, package managment for shipping, stock management, warehouse managment with bar code reader, parcel shops management on 3000 pickup points without local store.

Link to comment
Share on other sites

no

 

admin = admin

 

shop = shop

 

That they "named identical" , that they look simular.....

 

 

we can also say to all button : "push me... and see what happen"

 

 

i think it is best to accept it.

And when oscommerce team go change it.... accept then the change.

 

That's ok. Just a couple of questions:

- Can you tell me who exactly compose the oscommerce team? Are you one of them? Are there a list of contributors somewhere?

 

- I've understood fr now the current spirit of this project is something like: 'Let us, all of us, as community, get oscommerce one step better by helping as we can.' Did I understand it wrong? Should I shut up my opinion an let that 'oscommerce team' decide without even letting them know what I've found useful or what I see as a good improvement? Can't I purpose nothing?

 

I agree with you. Shop= shop, admin=admin. Bot oscommerce=oscommerce, I'm not talking about including a piece of code from an external source. I'm just saying it's not optimal to have two copies of the same classes and functions just because it was done that way 10 or 15 years ago. Things changes, you know...

Link to comment
Share on other sites

This would be the step by step direction of the development as you see in v3.

 

I didn't see v3 code, but if that's the idea, whoy  not start convergence with things like this?

Link to comment
Share on other sites

This is a bad idea from a security perspective. I've set up many stores with the admin in a separate domain, not under the store domain. This is only possible because osComemrce has a separate Admin structure. Combine them and you lower my security.

 

This is fine if you don't mind being hacked, but I'd rather not be.

 

Regards

Jim

See my profile for a list of my addons and ways to get support.

Link to comment
Share on other sites

@@wHiTeHaT thank you for the explanation. I am able to do this task even with my limited knowledge as it's easy.

 

I was just feeling that it's better to talk about an idea before doing it for nothing. The concept is clear and if some code mantainer considers it a good idea I'll do it. Otherwise I don't see why code something that will be go nowhere. And that's why I was asking you to tell me who the 'oscommerce team' is.

 

 

This is a bad idea from a security perspective. I've set up many stores with the admin in a separate domain, not under the store domain. This is only possible because osComemrce has a separate Admin structure. Combine them and you lower my security.

 

This is fine if you don't mind being hacked, but I'd rather not be.

 

Regards

Jim

 

That's another thing. If it's not good for security reasons that's enough for me.

 

But the idea of @@MrPhil to use the same file copied twice to avoid conflicts looks perfect for me. There are weird differences and inconsistences in some duplicated files.

Link to comment
Share on other sites

This is a bad idea from a security perspective. I've set up many stores with the admin in a separate domain, not under the store domain. This is only possible because osComemrce has a separate Admin structure. Combine them and you lower my security.

 

This is fine if you don't mind being hacked, but I'd rather not be.

 

Regards

Jim

 

I've been thinking about the schema you mention. Is there some way of manipulating shipping methods on that model? Being all the shipping and payment modules in the shop side I can't imagine how to accomplish this task.

 

Link to comment
Share on other sites

@piernasc  All of the module settings are stored in the database, so there's no problem at all with doing this. I have one store that I started in 2003 on osC 2.2MS2 that had a separate admin, and still does today on 2.3.4. It's never been hacked.

 

I also add a honeypot in a directory under the store named admin. It catches the wannabe hackers and bans them. It helps to keep the noise level down.

 

Regards

Jim

See my profile for a list of my addons and ways to get support.

Link to comment
Share on other sites

@piernasc  All of the module settings are stored in the database, so there's no problem at all with doing this. I have one store that I started in 2003 on osC 2.2MS2 that had a separate admin, and still does today on 2.3.4. It's never been hacked.

 

I also add a honeypot in a directory under the store named admin. It catches the wannabe hackers and bans them. It helps to keep the noise level down.

 

Regards

Jim

 

I also have an IP trap. Every day catches a few hackers! Just put a fake forbidden directory and they will go straight there :)

 

I meant about the modules themselves. I frequently have to change the shipping module of an order by request of the customer. Can this be done when you have separate admin and shop? Do they still communicate?

Link to comment
Share on other sites

Yes. All of that information is stored in the database. A separate admin is exactly as functional as one installed under the shop directory.

 

Regards

Jim

See my profile for a list of my addons and ways to get support.

Link to comment
Share on other sites

Using duplicate copies (if not the same physical file) between the store and admin sides would also help with the very common problem of overwriting the store configure.php with the admin copy, or vice-versa. Unfortunately, you need to update both copies in parallel, so it's not a matter of a one-time installation copy.

 

Is there a way to use a single copy (at run time) of various class, function, and configuration files; while still allowing stricter access control for admin (password protected, perhaps under SSL too)? As I said before, it's possible to copy various files from one side to the other during installation, but then you still have duplicate code (takes up space), and any changes to one need to be made to the other (add-ons too, not just the configure.php files). It would not be terribly efficient to copy a single source at run time, but it might be acceptable for admin to copy at startup from the store side (admin is run less often than the store). Thoughts?

Link to comment
Share on other sites

@@MrPhil I don't see the problem with holding the classes into the admin side and accessing them from the shop side; having both copies still gives acces to a hacker to the shop side files more easily than to the admin (if it's well protected), but now the code is there.

 

@@kymation Im'm not an expert in any way, but if you manage to access the shop side and you can read configure.php you will know location of the admin and password and user for the database and that's a game over, so I don't see a problem with having just one copy of the files as these are already there now.

Link to comment
Share on other sites

@@piernas  Please tell me where you find the admin location, username, or password in the shop side configure.php. If you're talking about the database, then yes it's there. That still does not give you file access. The automated scripts that hackers use require file access to the admin, and moving the admin out of the shop directory blocks those automated attacks. It's not perfect security by any means, but it helps.

 

Regards

Jim

See my profile for a list of my addons and ways to get support.

Link to comment
Share on other sites

@@piernas  Please tell me where you find the admin location, username, or password in the shop side configure.php. If you're talking about the database, then yes it's there. That still does not give you file access. The automated scripts that hackers use require file access to the admin, and moving the admin out of the shop directory blocks those automated attacks. It's not perfect security by any means, but it helps.

 

Regards

Jim

 

 

Yes you're right, no administrator access is located in configure.php but you have username and password for the database that stores username and encrypted password for admin, so that's a lot info i suppose. And with access to the database and the shop fileserver you won't need access to the admin as you can create your own admin I imagine. The most important and valuable part of the shop is the data, not the files.

 

In fact I've just imagined a hole in my shop related to this we're talking about. I'm fixing this right now!

 

About the directory I was thinking there was a reference to the admin location, but you're right, I didn't remeber well. It's on admin configure.php where you can locate the store location, sorry.

 

Anyway I don't see how a class shared in both sides could help a hacker; many files from store (payment modules, images and other) are used in both sides currently, so I don't see how using classes stored in the shop side could aggravate security issues, because the code is the same in both. Those files doesn't create anything but only read to the database, doesn't write files like other known old oscommerce security holes.

Link to comment
Share on other sites

There is an .htaccess file in the /includes directory that should prevent anyone from reading the configure.php directly. There may be indirect ways to get this information, so it's important to keep up on all of the security updates to your shop.

 

Even if someone did get your database username and password, they cannot normally access that database from anywhere except your server. If your host allows remote database access, make sure you keep that turned off. Then a hacker really does need file access to your server to access the database.

 

Shared files are not a problem in themselves, so long as the admin side knows where the files are. This can get tricky if the admin is on a different domain, and worse if it's on a different server.

 

Regards

Jim

See my profile for a list of my addons and ways to get support.

Link to comment
Share on other sites

Even if someone did get your database username and password, they cannot normally access that database from anywhere except your server. If your host allows remote database access, make sure you keep that turned off.

 

That's exactly what I saw when thinking about it. I've disabled it. Thanks!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...