Just want to ask your expertise regarding Orbeon, We created a form using From builder and we need to expose that publicly. So we setup our firewall to only allow the exact URL for the created form, sample below:
https://publicaddress/fr/ELO/ELOPreSales/new
However, it does not load properly, we also expose the following URLs:
https://publicaddress/orbeon/fr*
https://publicaddress/orbeon/xforms-server*
Page managed to load but some controls are not loading. When we checked using the developer tools, seems like we need to expose as well the root folder of the webapp:
https://publicaddress/orbeon*
I think this is not a best practice it anonymous uses will have access to the form builder, form runner, etc.
Any suggestion will be highly appreciated.
Thanks.
Exposing specific URLs via firewall
Instead of relying on a firewall I would recommend that:
If you don't need to have form builder accessible on that server at all, you can remove it entirely (doc).
If you need to keep Form Builder on that server, but want to authenticate form authors, damn this is something that you can set up in the form-builder-permissions.xml (doc).
And feel free to post a comment if your use case doesn't correspond to the situations I described above, or that I missed anything in my response.
Related
In a couple of places Form-Runner-~-Access-Control-~-Setup says
configure form-builder-permissions.xml as described above
But it appears that this documentation has been moved to another page. Should it be referring to Form Builder permissions?
The first paragraph on Form-Runner-~-Access-Control-~-Setup also says:
Form Runner uses the username, group, and roles to control who can access Form
Builder and the forms you create with Form Builder (see the two sections above
for more details on how those are setup).
There are no sections above on that page. I think it is referring to Editing Forms and Deployed Forms.
Mmmh… I removed that sentence from the documentation, as it doesn't seem to belong there. There are two parts you might want setup access control for: Form Builder and the forms you've deployed. The former is documented in Access Control ~ Editing Forms, the latter in Access Control ~ Deployed Forms. And in both cases, you need to do some initial setup, documented in Access Control ~ Setup.
Can we add php contact form in volusion eCommerce site?
I tried to implement but couldn't get it right.
Problem seems to me is, when calling the php file for form action to "XXX.php" file, it displays error (i.e. couldn't find the page).
Can I call "xxx.php" file from volusion "default.html" page??
Please help me out.
I know this question's a bit old but I thought I'd give you my thoughts on it anyways, You asked if you could use PHP on volusion and my answer to that is Unfortunately Not. Volusion only supports classic ASP and JavaScript on the front end of your store. (And as the previous poster said, it is written in asp.net however I've never been able to get .net code to work in it, it seems .net is only used for the admin panel and for the webservices API...)
Regardless, there are a few other ways to accomplish what you want to do; at least in my mind.
You could possibly add it with an Iframe.
If not, (if volusion blocks out your iframe, or if you just don't want an iframe) I would suggest just making your contact form in ASP or JS... You could view the following link for information on how to use their VSMPT ASP class.. http://support.volusion.com/article/vsmtp-key
If neither of the previous options work, you might also consider making the contact form be part of a new ticket. It would however require your customers to create an account first, and if it's purpose is to reach new customers you might want to look into how you add custom fields to the account registration form in volusion. This way you can have the information that you wish to collect from customers inside of your volusion admin panel.
This link may be helpful for the latter. http://support.volusion.com/article/use-custom-fields-gather-marketing-data
I wish you the best of luck working with volusion, I'm stuck on their disgusting software and sure wish I would have known the massive limitations and roadblocks, prior to starting using their product. Hopefully I'll be moving away soon! I suggest the same to anyone else on it. (sorry for the added two cents)
You can if your server will support it. What I mean by that is that Volusion is written in ASP.NET and runs on a Microsoft server. PHP on the other hand runs on a LAMP (Linux, Apache, MySQL, PHP) server.
Generally I don't find servers running both the LAMP stack and the Microsoft stack but its possible.
I have an ASP.net MVC website providing various admin functions. It's internal and uses Windows authentication to manage different roles access to various controllers and actions.
In order to achieve this I have decorated the various objects with [Authorize(Roles="")]
This project is now quite mature, and a search reveals I have used the attribute nearly 60 times - I'm now at the point where this is starting to feel insecure, and I need a way to affectingly manage who has access to what.
So what I really want to build is a site map type page that lists all views on the site with a list of roles that can access each view listed alongside.
I have searched but can't seem to find how to start - any pointer would be greatly received - thanks.
If you're feeling insecure about not having all controllers/controller actions managed something you could look at is Fluent Security.
It allows security to be specified in a centralized space and in a way that is readable.
There's a good tutorial on it here.
It won't give you your site map type page, but may give you some peace of mind.
We are using MVC on IIS6. Our site is currently being opened up, but we need to restrict access to the register part of the site, but allow those who can register (i.e. from within our offices) still to sign in and use the site fully.
So inside office can access register and all other site.
Outside office cannot access register and but can access all other site.
Initially, we put file restrictions for the IPs of our offices on the register.aspx file in the views\accounts folder. We were pretty sure this was working, but today, we discover it isn't! Which thinking about it actually makes sense!
So is this possible?
We need to have the other aspx pages in the views\accounts folder usable as views whilst only blocking the register view.
Hope this makes sense!
Neil
Urls defined with ASP.NET MVC are configurable and not based on the folder or file where view page resides.
This means that you cannot use IIS to configure the access for this view pages.
You can filter access to the controllers (and so indirectly the view pages that are called by the view pages). This is done with Action Filtering. On how to create a custom action filter see this page.
So yes, it is possible to limit access to certain pages depending on the ip-address.
I have come across this kind of situation before, but the problem was solved by the way we write applications.
Whenever we've had an application with "some information displayed" and "a way to administer the data" we've always created separate UI projects over the top of the business logic. This isn't just to help with maintainability, it also means that the public bit can be deployed on a public website, while the admin bit can be accessed over the network - so there is no external access at all.
In your example, extracting out the two logical elements would mean that you can deploy two separate web projects with different access rules in IIS.
Another option would be to check the IP address in the executed code for the restricted page - IP addresses can be spoofed, so it's not a completely secure solution.
As a relative newcomer to both web and MVC, I am looking for a good summary of security best practices that I should implement.
The site will be public facing with "moderately sensitive data" (meaning we can't get sued, but probably wouldn't make many friends if the data got out!) and will have the following security steps taken:
a: Forms/membership authentication and authorization
b: Parameterized queries to prevent sql injection.
c: Automatic timeout with x min of inactivity
c: SSL for client to server encryption
What else do you recommend?
*Securing IIS and the network don't fall under my domain, so I'm more interested in the things I need to do to the software.
If you are using cookies to recognize users, be sure to use an arbitrary token (such as a GUID) to store on the client for identification. I've seen too many websites that store my email address or username in my cookie... just have to change it to another!
Write your software so that it can run under medium trust.
If you are new to web development you should be aware of cross site scripting (XSS). You can use Http.Encode helper method to protect against this in ASP.NET MVC.
Make sure you prevent out of order requests. Ensure client is authenticated before allowing to see sensitive data, or in some cases, make sure the client has come through the correct channel, before allowing a data manipulation. For example, only allow adding an item to your cart if the request came from the product details page. If you don't check, any one can mess around with the action. The URL would be like http://server/cart/add/XYZ123 and anyone could just tweak the 'id' parameter.
Here's another biggie to watch out for: CSRF
http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
Take a look at this post by Phil Haack- one of the MS dev’s involved in the development.
Additionally take a look at Microsoft Anti-Cross Site Scripting Library to filter out all incoming parameters
Maybe you should choose methods that can be invoke from outside or not. For example be careful make a method like delete any tables like http://yourhost.com/edit/deletealltable.
Make sure you design your class and methods well. And give attributes [NonAction] for preventing public method being invoke.
Make sure you display data (especially sensitive) as you need with minimum fancy design and use client script as long as needed.
Remove any unused trash files like unused files in your solution folder.
Check and double check and validate any input control like textbox. I just can give something in the textbox to hack your system.
If you use mix between MVC and regular ASP.NET, please remove any dependency between them.
Be sure you cover the basics thoroughly, independently of ASP.NET. Make sure your DBMS has a separate user with the minimal required privileges (e.g., CRUD and executing sprocs from specified databases) set up to access the database from the web application. Parameterizing queries is an excellent idea, but ALWAYS SCRUB YOUR INPUT ANYWAY: it is not a complete defense against sql injection.
Keep your design clean and easy to understand. Document whatever you do clearly, especially on the database side. It would be very bad if all your good work were destroyed by two programmers months or years later--one who didn't realize, say, that the database user for the web application (now accessing a database on a different server) shouldn't have root privileges, and another who added a control that didn't cleanse input properly. There's only so much that can be done about this sort of thing, but designing for the possibility that fools will be maintaining your code isn't so that coders will think you're sweet--it's so that fools won't put you out of business.