I'm wondering if there is a way to validate FHIR profiles?
By this I mean validate the xml definition of my profile/extensions are valid, not validate a resource against my profile.
I'm asking this because I've build a tool for producing profiles, and I need to test that the output is correct (and I can't find a definitive clear document that states what is right and wrong).
I'm using HAPI if that makes a difference.
the best way is to use the implementation guide publisher. See http://wiki.hl7.org/index.php?title=IG_Publisher_Documentation#Command_Line_Mode - look for the alternative mode
Alternatively you can upload your StructureDefinition to Simplifier.net, which will do basic validation of the StructureDefinition. When it renders correctly on the Simplifier site after uploading, you'll know you're SD is valid.
Related
I have legal contract for this purpose.
I was trying to perform XSS attack on a website which uses ASP.NET. It's form validation is preventing me to enter payload. Is there any way to bypass that?
Certain unicode characters make it through.
But it realy depends what you are trying to achieve. If you need to prove the point that request validation is not enough to protect gainst XSS than you realy need to find such a payload.
The more common task would be: find the parts in the application that are affected by missing encoding of the output. For that you would need remove request validation in a test environment.
Is it possible to create a page in asp.net that allow the access to a user that has a defined IPaddres? My goal is to add a page "test" (not linked to my website) and I want to define a rule that only a specified IP address can get the access.
How can I implement this throught asp.net?
You could try putting the page(s) in a separate folder and password protect it, then, give the password to your user, so they may access the content. You could go as far as password protecting each file. This helps if your website is password protected or has a login.
You could also create a sub-domain for that user specifically.
These are just a few. I'm sure you'll get better suggestions here on SO!
You could go for a programmatic solution. However, I would use IIS functions to block the access. Less code, easier to configure and no hassle on your developement/test environment.
Assumption: you are using IIS since it is ASP.NET. But other webservers should have similar solutions.
You can add IP restrictions to the directory (meaning you would have to put your page in a separate directory). Example here: http://www.therealtimeweb.com/index.cfm/2012/10/18/iis7-restrict-by-ip
Obviously there are a lot of other and arguably better ways to grant access to a page if what you really want is for a specific "user" or "group" to have access, but assuming that your really want the access control to be based on IP, the answer may still be dependent on peripheral concerns such as what web server you are using. IIS for example has some features for IP based security that you could check out.
Assuming though that you really, really want to check IPs and that you want to do it in code, you would find information about the calling environment in the Request of the current HttpContext, i.e. context.Request.UserHostAddress.
If you want to reject calls based on this information, you should probably do that as early as possible. In the HttpApplication.BeginRequest event you could check if the call is targeted for the page in question and reject the request if the UserHostAddress is not to your liking.
If you prefer to make this control in the actual page, do it in some early page event.
To manage the acceptable IP(s), rather than hard coding them into your checking code, I suggest you work with a ConfigurationSection or similar. Your checking code could be something similar to:
var authorizedIps =
authorizedIpConfiguration.Split(',').Select(ipString => ipString.Trim()).ToList();
isValid = authorizedIps.Any()
&& authorizedIps.Contains(context.Request.UserHostAddress);
If the check fails, you should alter the response accordingly, i.e. at least set its status code to 401 (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes).
NB: There are a lot of things to consider when implementing security features, and the general recommendation would probably stand as "don't do it" - it's so easy to falter. Try to use well proven concepts and "standard implementations" if possible. The above example should not in itself be considered to provide a "secure" solution, as there are generally speaking many ways that restricted data can leak from you solution.
EDIT: From you comment to the answer given by nocturns2 it seems you want to restrict access to the local computer? If so, then there is a much easier and cleaner solution: Just check the Request.IsLocal property. It will return true only for requests originating from the local computer, see HttpRequest.IsLocal Property
(Also, you should really make sure that this "debug page" is not at all published when deploying your solution. If you manage that properly and securely, then perhaps you do not even need the access check any more. If you want debugging options in a "live" environment, you should probably look to HttpContext.Current.Trace or some other logging functionality.)
I've a home-made php based web calendar which I would like my users to import into Google Calendar, iCal, etc. so they have up-to-date information available on their calendar of choice. I understand providing a webcal link is the way to go but I am not sure how to create it. I've donwloaded an example .ics file but did not have much info..
Where can I find more info on creating a webcal feed? Also, does webcal allow authentication? The feed will most likely be password protected.
Thanks!
A webcal feed use iCalendar format as defined in RFC 5545. It's a rather complex and cumbersome format. You'll find simple examples on wikipedia which may fit your needs. You could also opt to use a library to abstract the format, such as:
http://framework.zend.com/svn/framework/laboratory/Zend_Ical/
http://bennu.sourceforge.net/
http://sourceforge.net/projects/icalcreator/
http://sabre.io/vobject/
From all of these the last one might be your best bet (all others seemed to be dead last time I checked).
As for authentication you may use basic HTTP authentication. Or use a secret token to identify the user (as seen in Google Calendar). Anyway, in both cases you probably should use secure connection (SSL) so data (and passwords) are not sent in clear.
And finally I would recommend the use of webcal:// or webcals:// scheme for ease of use for end-user. But you may face troubles with some clients (eg: Outlook 2007 and forced SSL). I don't have a work-for-all solution yet...
EDIT
I forgot to mention the ICS validator in case you don't use a lib .
I wanted to know if JSON is still used in live applications? I am creating a service and want to understand if I should output data using JSON too?
What is the latest standard now?
JSON is very popular, and there is no sign that this is changing.
I am creating a service and want to understand if I should output data using JSON too?
You really need to ask the potential customers of the service that question. Or at least, give us some hint as to what the service is and what clients are likely to use it.
What is the latest standard now?
There is no official standard for JSON. In theory, JSON is a subset of ECMAScript (aka JavaScript), so the relevant ECMAScript standard would be normative.
In practice, JSON is implemented in many languages independently of ECMAScript. The description on the JSON.org website, and IETF RFC 4627 are probably the most relevant to someone implementing JSON for themselves, but neither of these sources have the authority of a standard. If you want JSON libraries, the JSON.org site is a good place to start looking.
Yes, JSON is still very popular. Even Google web services API gives search output in JSON.
Take a look at this example:
http://zamples.com/JspExplorer/samples/google.jsp
Overwhelmingly yes. For me, JSON is the transport format of choice for AJAX requests and inter-application data sharing. To date, there are 1271 questions about JSON on SO.
Looking around, I can't name a single web application (not web service) that uses anything besides GET and POST requests. Is there a specific reason for this? Do some browsers (or servers) not support any other types of requests? Or is this only for historical reasons? I'd like to make use of PUT and DELETE requests to make my life a little easier on the server-side, but I'm reluctant to because no one else does.
Actually a fair amount of people use PUT and DELETE, mostly for non-browser APIs. Some examples are the Atom Publishing Protocol and the Google Data APIs:
http://www.ietf.org/rfc/rfc5023.txt
http://code.google.com/apis/gdata/docs/2.0/basics.html
Beyond that, you don't see PUT/DELETE in common usage because most browsers don't support PUT and DELETE through Forms. HTML5 seems to be fixing this:
http://www.w3.org/TR/html5/forms.html#form-submission-0
The way it works for browser applications is: people design RESTful applications with PUT and DELETE in mind, then "tunnel" those requests through POSTs from the browser. For example, see this SO question on how Ruby on Rails accomplishes this using hidden fields:
How can I emulate PUT/DELETE for Rails and GWT?
So, you wouldn't be on your own designing your application with the larger set of HTTP verbs in mind.
EDIT: By the way, if you're curious about why PUT/DELETE are missing from browser based form posts, it turns out there's no real good technical reason. Reading around this thread on the rest-discuss mailing list, especially Roy Fielding's comments, is interesting for some context:
http://tech.groups.yahoo.com/group/rest-discuss/message/9620?threaded=1&var=1&l=1&p=13
EDIT: There are some comments on whether AJAX libraries support all the methods. It does come down to the actual browser implementation of XMLHttpRequest. I thought someone might find this link handy, which tests your browser to see how compliant the HttpRequest object is with various HTTP options.
http://www.mnot.net/javascript/xmlhttprequest/
Unfortunately, I don't know of a reference which collects these results.
Quite simply, the HTML 4.01 form element only allows the values "POST" and "GET" in its method attribute
Some proxy servers with tough security policies might drop them. I'm using PUT and DELETE anyways.
I've read that some browsers do not support other HTTP methods properly, though I can't name any specifics.
Rails, in particular, will pack your forms with a method parameter to explicitly set this even if the browser doesn't support those methods. That seems like a reasonable precaution if you're going to do this.
I say use all the features of HTTP, browsers be damned, lol. Maybe it'll inspire more complete and proper use of the HTTP protocol moving forward. There's more happening on the net than just POSTs and GETs. About time browser implementations reflected this.
This depends on your browser and Ajax library. For example jQuery supports all HTTP methods even though the browser may not. See for example the jQuery "ajax" documentation on the "type" attribute.
The Restlet Java framework lets you tunnel PUT and DELETE requests through HTML POST operations. To do this, you just add method=put or method=delete to your URI's query string, eg:
http://www.example.com/user=xyz?method=delete ...
This is the same as Ruby on Rails' approach (as described by #ars above).
Personally, I really don't see any purpose for using PUT or DELETE in a web application. All operations that an application performs are read or write, aka input output. Why do you need to distinguish the nature of the operation in the header of the HTTP request?
I could make ajax calls with the same url of form /object/object_id
and do multiple operations like delete, update, get the value, or create.
Just by looking at the URL, I have no clue which one it is.
By using GET and POST only, my urls will be:
/object/id/delete
/object/id/create
/object/id/update
/object/id --> implied GET
etc.
Based on my limited experience, this is a lot cleaner than hidden header request types in many cases.
I am not saying one should never use PUT or DELETE, just saying, use them only if absolutely needed.
Refer to "RESTful Web API" by Leonard Richardson to read more about different use cases and conventions regarding HTTP request methods in a RESTful web api.