I will be making demo version of Magento for a showcase. I want to give users admin credentials so they can see what Magento's administration has to offer.
a) Am I exposing server to some kind of security threat? I know that you can upload extensions through admin panel.
b) Users will click anything, I am sure of that. So I will make a cronjob to override database and files with backup in a certain time period.
I am not sure what kind of Magento user roles are, I need to look into it, maybe I can find a solution.
What is your opinion? Thank you in advance.
The best way is to create a new user and provide it with the permission to limited access. If you are not familiar to magento's user roles then this will be the best place to look for.
I suggest you to backup your database for the safety.
Hope this will help.
Related
I know this looks like a dumb question, but I just found out that, last month, something terrible happened to my GitLab instance: someone signed up on it and became admin himself, without my invitation, as I was the only administrator. So he wiped off every internal and/or private project inside of it, groups too (and I don't even know whether he had stolen all of them before erasing or not, I'm worried because they were proprietary code). How did it happen? Does this have anything to do with, since the version was CE-13.3.0? If so, would version upgrading be enough to be safer, or should I make some particular configurations, such as disabling sign up page?
It is best to follow "GitLab instance: security best practices", which does include indeed:
Ensure open sign-up is disabled on your instance.
Open registration is disabled by default on self-managed instances with GitLab 13.6 and above installed.
If new sign-up is enabled and your instance is open to the internet, anyone can sign up and access data.
Administrators who would like to further restrict access on their instance can follow our documentation on how to configure user access.
Regarding the CVE mentioned, follow also "Action needed by self-managed customers in response to CVE-2021-22205", in your case: "CVE-2021-22205: How to determine if a self-managed instance has been impacted" (unless the log events have been wiped out as well).
We're planning to use Sharepoint 2010 as a CMS for a website we're building. This site will also have login functionality; and my boss suggested we use Sharepoint's user profile features to store user info (username, password, contact info, etc.) for the site. How is this better then say using a standard list or a database table somewhere? I'm looking into how this could possibly work; but has anyone here tried something similar? Any anecdotes about it you could share? Any constructive input is greatly appreciated.
Thanks,
Frank
You asked for anecdotes. I have an anecdote.
A while back, I was trying to set up a Sharepoint server that exposed users' personal pages to the Internet at large. We wanted to allow authenticated access, but not to require it; that is to say, normal users would have read-only access and additionally the ability to submit InfoPath form data to Sharepoint libraries created to receive the results. The users could thus post public information and create public surveys using Infopath web forms.
When I went to make access public, I ran into a few problems. The "unauthenticated users" option on the preferences page of the document library was greyed out, even when I was logged in with a super-admin account.
In the end, I had to do a little bit of URL hacking to make this work. I had to change "DOC" to "DOCLIST" in the URL I used to access the preferences page (not that exactly, but something like that) and then the "everyone" option became available. In other words, there was actually no official way to do what I was trying to do.
The whole thing left a really sour taste in my mouth about Sharepoint for Internet-facing sites. See also things like this. Sharepoint is really designed for Intranet use only. As an additional downside, it is much more resource-hungry than normal CMSen. A full Sharepoint install can, without a single user, choke a pretty powerful virtual machine. I can't comment on its scalability as I've never done a really large rollout, but I can say that the indexing service is pretty heavy on the CPU.
Seems to me that LDAP would be a better way to store information on users; if you're using Sharepoint, you've probably already got an AD infrastructure. AD stores user profile info in LDAP anyhow - what you see in "Active Directory Users and Computers" is just a glorified LDAP browser.
Here is my initial toughts:
PRO: It's "easy" to merge infomation from outer sources like your AD, to be stored with the "other" user information in order to be displayed using the same means.
CON: I haven't come across a FBA Membership provider for User Profile Store.
I am not being paid for this and I would like to know the quickest way to do the following. A former client has a page which only members can access. This page links to a number of galleries which he only wants members to access. The galleries are not protected by any kind of authentication.
What I assume is the quickest way to do this is to create a .htaccess file which only allow people to view the site when the come from a certain referrer. Would this work?
My current thinking is that I could use a php script to deploy a .htaccess file into each of the gallery directories. (There are around a 100 at the moment.)
I found this link which might be what I am after but to be honest I really don't get it. Is my thinking sound? Could someone either link me to a tutorial that does this or show me how it is done.
http://perishablepress.com/press/2006/01/10/stupid-htaccess-tricks/#sec7
As always, a massive thank you for any help.
Jason
Can someone please tell me how to do the following in SharePoint (WSS 3.0):
Have a user log in (user name and password) on a page and then if correct display the home page of a WSS 3.0 site?
I think it's called forms based authentication.
Here's a video about using Forms Auth. with WSS3 and here are some samples. Basically, you use the login.aspx page in _layouts to collect credentials and cache them. You have to modify web.config to use the membership provider. More on that here.
This is one of the best article on FBA
Save yourself a lot of time and checkout http://sharepointsolutions.com/SharePoint-Add-ons/Products/Pages/ExtranetCollaborationManager.aspx
I have done it several ways but this has made life easier when configuring environments.
As a special case of Forms Based AuthN, in case you don't have to own the DB containing your users, you can rely on Live ID to authenticate users to your site. Haven't tried this, but may help you.
I just believe some JavaScript is enough to do that.Maybe I am Wrong!
In our Sharepoint implementation users have been granted site collection admin rights. On a few occasions they've managed to delete a subsite or even the entire site collection. I'd like to be able to block this but not being a developer I'm finding it pretty tricky.
I've had a look at the MSIT site delete capture tool to try to understand how that's working and it seams fairly straight forward. I want to override the delete function and either block it entirely or have the user type a password. What I can't see is any way to fully override the default behavior as it looks like the MSIT tool simply adds some functionality (backs up the site) then falls back into the default behavior.
So my question is, can I prevent the default behavior or can I only add actions before or after it fires?
Thanks in advance
Change the user permissions may be the best way to go. site collection admin is a crazy level of access for normal users.
Two answers:
You cannot prevent site deletes without either coding up something yourself, or buying a product to help you with "site lifecycle management" or "site governance" or some other vague term they use to describe this sort of thing.
The Site Delete Capture Tool may be good enough for you. It doesn't prevent any kind of deletions, but it does take a crude backup that (hopefully) allows you to restore anything they delete. We're using this tool in production and it works.
You could try to edit the site settings aspx file and comment out the delete site link, don't have a setup around to try that. While users could delete the site in other ways it would prevent the most common method.
Other option for important sites would be to make sure the site has a sub-site, if one does not already exist create one and don't user any access. The site would not be seen by the users and it would prevent them from deleting the parent site.
As for programming, in the before behavior you can return a false to stop the action. Just be sure to place a work around so you can delete a site.
A Site Collection administrator has the permission to delete sites and it should stay that way. We have modified MSIT to do additional stuff
The best way to limit user privileges is to put users in the right SharePoint group (ie) Owners, Members, Visitors or you could create a new group with right permission/permission levels.