suppose the DogManagementPro program is an application written in client/server architecture, where the customers who buys it is supposed to run the server on his own PC, and access it either locally or remotely.
suppose I want to support a "list all dogs" operations in the DogManagementPro REST API.
so a GET to http://localhost/DogManagerPro/api/dogs should fetch the following response now:
<dogs>
<dog>http://localhost/DogManagerPro/api/dogs/ralf</dog>
<dog>http://localhost/DogManagerPro/api/dogs/sparky</dog>
</dogs>
where I want to access it remotely on my local LAN, [the local IP of my machine is 192.168.0.33]
what should a a GET to http://192.168.0.33:1234/DogManagerPro/api/dogs fetch?
should it be:
<dogs>
<dog>http://localhost/DogManagerPro/api/dogs/ralf</dog>
<dog>http://localhost/DogManagerPro/api/dogs/sparky</dog>
</dogs>
or perhaps:
<dogs>
<dog>http://192.168.0.33/DogManagerPro/api/dogs/ralf</dog>
<dog>http://192.168.0.33/DogManagerPro/api/dogs/sparky</dog>
</dogs>
?
some people argue that I should subside the problem altogether by returning just a path element like so:
<dogs>
<dog>/DogManagerPro/api/dogs/ralf</dog>
<dog>/DogManagerPro/api/dogs/sparky</dog>
</dogs>
what is the best way?
I've personally always used non-absolute urls. It solves a few other problems as well, such as reverse / caching proxies.
It's a bit more complicated for the client though, and if they want to store the document as-is, it may imply they also now need to store the base url, or expand the inner urls.
If you do choose to go for the full-url route, I would not recommend using HTTP_HOST, but setup multiple vhosts, and environment variable and use that.
This solves the issue if you later on need proxies in front of your origin server.
I would say absolute URLs created based on the Host header that the client sent
<dogs>
<dog>http://192.168.0.33:1234/DogManagerPro/api/dogs/ralf</dog>
<dog>http://192.168.0.33:1234/DogManagerPro/api/dogs/sparky</dog>
</dogs>
The returned URIs should be something the client is able to resolve.
Related
What's the best practice when you have dependencies that you want to be able to configure when creating a PowerShell module in C#?
My specific scenario is that the PowerShell module I am creating via C# code will use a WCF service. Hence, the service's URL must be something that the clients can configure.
Is there a standard approach on this? Or will this be something that must be custom implemented?
A somewhat standard way to do this is to allow a value to be provided as a parameter or default to reading special variable via PSCmdlet's GetVariableValue. This is what the built-in Send-MailMessage cmdlet does. It reads the variable PSEmailServer if no server is provided.
I might not be understanding your question. So I'll posit a few scenarios:
You PS module will always use the same WCF endpoint. In that case you could hardcode the URL in the module
You have a limited number of endpoints to choose from, and there's some algorithm or best practice to associate an endpoint with a particular user, such as the closest geographically, based on the dept or division the user is in, etc.
It's completely up to the end user's preference to choose a URL.
For case #2, I suggest you implement the algorithm/best practice and save the result someplace - as part of the module install.
For case #3, using an environment variable seems reasonable, or a registry setting, or a file in one of the user's profile directories. Probably more important than where you persist the data though, is the interface you give users to change the setting. For example if you used an environment variable, it would be less friendly to tell the user to go to Control Panel, System, Advanced, Environment, User variable, New..., than to provide a simple PS function to change the URL. In fact I'd say providing a cmdlet/function to perform configuration is the closest to a "standard" I can think of.
How can I define a variable that is accessible over several #include levels? E.g. I have some DIM declared in a VBScript and I want to access this by name inside an included VBScript so it is accessible for one user/one session which must be equal to session("UserID") if I have disabled sessions at all and also do not use cookies.
If you want to keep the variable state through multiple page requests and can't use cookies nor session state, an option i see is carrying it in the query string of each request url.
Or maybe you can also look at html5 local storage. Despite some people depreciating w3schools, i always find it a good starting point.
Well, it's been a very long time since I've last worked with ASP3 and VBScript, but if memory serves, the #Include directive is actually not a part of the ASP, it's an instruction to the IIS to add the file that is included into your ASP page.
Therefor any function or variable declared in an included file should be considered for all intents and purposes as if it was written directly into your ASP page.
As you should know, VBScript can't use a variable unless it's declared in a previous code row, therefor it's only a matter of where in your ASP page you are using the #Include directive.
This is why you should use the #Include directive as soon as possible in the ASP page that uses them.
Cookies, sessions (cookie-sessions), local storage values, are the most common types to track a visitor. Another unrealiable option is to store the values in a DB table and then use a mix of IP address and other browser sniffing variables to indicate a user (this is a bad idea).
Your best bet is to use standard cookies and keep ASP-SESSIONS off. Then you would have to build your own session management, which is usually done in a Database.
As for getting those session values into ASP and playing with them on the server side, you just do a request.cookies("session-coookie-name") and then look up the session in your DB. If you want this to go across all pages of your site put it in an include file and make sure that include file is included in all of your asp scripts.
When coding Classic asp, I usually start with a boiler plate which has a few includes (include-page-start.asp, include-head-asp, include-menu.asp, include-page-end.asp). Having an approach like this allows you to quickly add functionality without having to edit every page later. Remember includes can also include other includes :) (part of the reason asp classic both sucks and rocks!)
Sessions also use cookies to track visitor.
But ASP-SessionID Cookie does not have an expire time so if you close your browser, your cookie with ASP-SessionID will delete and your session will be terminated.
i think you try to build a load balance on an ASP site which is most complicated thing with session variables.
You have to use something different to track visitors. Cookies are an option but you have to create your own session management and still have to use a cookie to remember it.
i found a new component to do this. it work like a charm for load balance and keep your own session management with multi accesible mechanism.
http://www.aspstate.com/Developer/Documentation/html/R_Project_Documentation.htm
As I understood after reading these links:
How to find out what does dispatcher cache?
http://docs.adobe.com/docs/en/dispatcher.html
The Dispatcher always requests the document directly from the AEM instance in the following cases:
If the HTTP method is not GET. Other common methods are POST for form data and HEAD for the HTTP header.
If the request URI contains a question mark "?". This usually indicates a dynamic page, such as a search result, which does not need to be cached.
The file extension is missing. The web server needs the extension to determine the document type (the MIME-type).
The authentication header is set (this can be configured)
But I want to cache url with parameters.
If I once request myUrl/?p1=1&p2=2&p3=3
then next request to myUrl/?p1=1&p2=2&p3=3 must be served from dispatcher cache, but myUrl/?p1=1&p2=2&p3=3&newParam=newValue should served by CQ for the first time and from dispatcher cache for subsequent requests.
I think the config /ignoreUrlParams is what you are looking for. It can be used to white list the query parameters which are used to determine whether a page is cached / delivered from cache or not.
Check http://docs.adobe.com/docs/en/dispatcher/disp-config.html#Ignoring%20URL%20Parameters for details.
It's not possible to cache the requests that contain query string. Such calls are considered dynamic therefore it should not be expected to cache them.
On the other hand, if you are certain that such request should be cached cause your application/feature is query driven you can work on it this way.
Add Apache rewrite rule that will move the query string of given parameter to selector
(optional) Add a CQ filter that will recognize the selector and move it back to query string
The selector can be constructed in a way: key_value but that puts some constraints on what could be passed here.
You can do this with Apache rewrites BUT it would not be ideal practice. You'll be breaking the pattern that AEM uses.
Instead, use selectors and extensions. E.g. instead of server.com/mypage.html?somevalue=true, use:
server.com/mypage.myvalue-true.html
Most things you will need to do that would ever get cached will work this way just fine. If you give me more details about your requirements and what you are trying to achieve, I can help you perfect the solution.
My goal is to have this:
.com/english-urls - English (United States)
.com.br/portuguess-urls - Portuguess (Brazil)
.com.mx/spanish-urls - Spanish (México)
...
I already have working multilingual functionality using this Language Switcher: http://www.yiiframework.com/wiki/293/manage-target-language-in-multilingual-applications-a-language-selector-widget-i18n/
And URL localization using this: http://www.yiiframework.com/wiki/55/i18n-subdomains-and-url-rules/
Any idea on how to have the multi top level domain functionality?
Thanks in advance to contribute to Yii development.
There are a few different ways you can approach this.
Parameterized host names. See the guide for details on how to set it up: http://www.yiiframework.com/doc/guide/1.1/en/topics.url#parameterizing-hostnames
Use environment variables set as part of your web server depending on the domain name being used.
I've done #1 in the past and it works pretty well. One nasty side effect comes up if you have a site that runs with SSL but your devs work with non-SSL machines. Parameterized host names require the full http:// or https:// as part of the URL rule unless you extend CUrlManager.
Another bug I hit recently occurs if you use parameterized hostnames AND a baseUrl (https://github.com/yiisoft/yii/issues/3520). Probably not something to worry about, but an FYI that it is there.
Which is why the idea of using environment variables intrigues me. You might be able to load only rule sets that match your given language, etc. but I haven't personally built a system using that approach.
Finally I got a solution!
Using this class: http://www.yiiframework.com/wiki/55/i18n-subdomains-and-url-rules/
1.- Define your top level domains list.
public $domainList = array('www.example.com.mx' => 'es', 'www.example.com' => 'en');
2.- Comment the unnesesary code.
3.- Detect SERVER_NAME and save as activeLanguage.
$languageCode = $this->domainList[$_SERVER['SERVER_NAME']];
$this->activeLanguage = $this->isSupportedLanguage($languageCode);
3.- Create the links in your header or main.
Thanks to twitter.com/atrandafir and acorncom for contribute!
I'm trying to write a greasemonkey script that will work on either Chrome and Firefox.. a script that will block XMLHttpRequest to a certain hard-coded url..
I am kind of new to this area and would appreciate some help.
thanks.
it possible now using
#run-at document-start
http://wiki.greasespot.net/Metadata_Block#.40run-at
but it need more improvement, check the example
http://userscripts-mirror.org/scripts/show/125936
This almost impossible to do with Greasemonkey. It is the wrong tool for the job. Here's what to use, most effective first:
Set your hardware firewall, or router, to block the URL.
Set your software firewall to block the URL.
Use Adblock to block the URL.
Write a convoluted userscript that tries to block requests from one set of pages to a specific URL. Note that this potentially has to block inline src requests as well as AJAX, etc.