i am using "gulp-connect" as a development server and i am trying to implement react router 1.0.0-rc1.
Currently i am using "createHashHistory" which adds junk something like: ?_k=ckuvup in the URL, which is deliberate as defined in the document. I am ok with it until i am sending query strings along with URL and my link looks something like this with the junk appending just after the domain name rather then at the end:
http://localhost:8080/#/?_k=y754gg/jobs?latitude=27.686784000000003&longitude=85.2690875&query_location=Liverpool, United Kingdom&query=fjdkf
Expected URL (something like this) :
http://localhost:8080/#/jobs?latitude=27.686784000000003&longitude=85.2690875&query_location=Liverpool, United Kingdom&query=fjdkf/?_k=y754gg
I could have used "createBrowserHistory" which has a much clear URL but the problem is:
1) Server configuration. Example provided only shows how to do in Express. I am planning to use nginx in production and am using gulp-connect in development. As i could not find any reference on how to do in this servers i had to choose "createBrowserHistory".
2) My backend is on rails and if i through my front end in "public" folder, URL with # should separate client and server routes. But i keep on thinking there must be a way to use createBrowserHistory with some configuration in nginx.
My priority from this question is the first part on appending the key at the end. Any reference on how configuration are done in different server will be appreciated.
You should be able to disable the URL hash by setting queryKey: false when creating your history:
var history = History.createHashHistory({
queryKey: false
});
Related
Context
I've been running an intranet admin panel in Symfony 3.x for several years. The users login with google oauth and the system checks if the email matches a validated one in a lookup-list. The oauth client handling is done with the "HWI OAuth Bundle".
In order to start a clean way to migrate this admin panel into SF4 and later to SF5 we've started breaking our monolyth into microservices running in docker.
Moving to docker behind a reverse proxy
Today we were moving this admin panel into a docker. Then we are having the public apache2 doing a ProxyPass towards the docker running the admin panel. Let's imagine the docker runs in http://1.2.3.4:7540 Let's assume the public address is https://admin-europe.example.com
What happens is that the symfony application has a relative URL, as the route google_login configured in the routing.yml and in the service configuration defined in the security.yml:
routing:
# Required by the HWI OAuth Bundle.
hwi_oauth_redirect:
resource: "#HWIOAuthBundle/Resources/config/routing/redirect.xml"
prefix: /connect
hwi_oauth_connect:
resource: "#HWIOAuthBundle/Resources/config/routing/connect.xml"
prefix: /connect
hwi_oauth_login:
resource: "#HWIOAuthBundle/Resources/config/routing/login.xml"
prefix: /login
# HWI OAuth Bundle route needed for each resource provider.
google_login:
path: /login/check-google
logout:
path: /logout
security:
firewalls:
# disables authentication for assets and the profiler, adapt it according to your needs
dev:
pattern: ^/(_(profiler|wdt)|css|images|js)/
security: false
secured_area:
anonymous: true
logout:
path: /logout
target: /
handlers: [ admin.security.logout.handler ]
oauth:
resource_owners:
google: "/login/check-google"
login_path: /
use_forward: false
failure_path: /
oauth_user_provider:
service: admin.user.provider
So when the application was not dockerized, it run properly because the route requested to be the "redirect route" to google was https://admin-europe.example.com/login/check-google.
Nevertheless, now that it's inside the docker when the HWI bundle is building the data block to send to google it requests for this http://1.2.3.4:7540/login/check-google to be authorised as the "redirect URI" but of course it should not. Of course the redirect URI should continue to be https://admin-europe.example.com/login/check-google.
I naturally get this error message:
The reverse proxy
We already have in the reverse proxy the ProxyPassReverse and, in fact, the very same configuration has been working hassle-free for over a month with another microservice we already successfully moved (but that service did not need auth, was a public site).
This is natural, as ProxyPassReverse will tackle into http data but the google-oauth info-block is not handled by the ProxyPassReverse, as it's natural.
The problem
The problem here is not to have this address validated (put a domain alias into the private IP address, etc.)
The problem here is how to generate the "proper public URL" from inside the docker without creating a hard-dependency for the container contents in function of the environment it's going to run. Doing so would be an anti-pattern.
Exploring solutions
Of course the "easy" solution would be to "hardcode" the "external route" inside the container.
But this has a flaw. If I also want the same docker to be accessed from, say, https://admin-asia.example.com/ (note the -asia instead of the -europe), I'll run into problems as the asia users will be redirected to the europe route. This is a mere example, don't care about the specific europe-asia thing... the point is that the container should not be conscious of the sorrounding architecture. Or at least, conscious to "interact" but definitively not to have "hardcoded" inside the container things that depend on the environment.
Ie: Forget about the -europe and -asia thing. Imagine the access is admin-1111. It does not make sense that I have to "recompile" and "redeploy" the container if one day I want it to be accessible as admin-2222.
Temporal solution
I think it would solve the problem to point both the route in the rounting.yml and the config in the security.yml to a "parameter" (in 3.x in parameters.yml) and then move that into an Environment Variable when updating to SF4, but I'm unsure on how the cache compiler of the symfony would behave with a route that does not have a value, but a route that "changes dynamically".
Then pass the value of the redirecion when the container is started. This would solve the problem only partially: All the container would be bound to a redirect route set at the time of start, but it still would not solve the case of the same container instance accessed via different names thus needing multiple redirect routes. Instead when running non-dockerized that works as it just takes the "hostname" to build the absolute path on a relative-path definition.
Investigation so far
When accessing, the browser shows I'm going to
https://accounts.google.com/o/oauth2/auth
?response_type=code
&client_id=111111111111-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.apps.googleusercontent.com
&scope=email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fplus.profile.emails.read+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fplus.login
&redirect_uri=http%3A%2F%2Fmy.nice.domain.example.com%3A7040%2Fapp_dev.php%2Flogin%2Fcheck-google
Here we see that the redirect_uri parameter is the place where we'll return after passing the control to google momentarily.
So somebody needs to be building this URL.
I seeked for "redirect_uri" within the source code and I found that the involved classes are GoogleResourceOwner which extends GenericOAuth2ResourceOwner.
Both classes seem to belong to the domain as per the tests passing the $redirectUri as a string which needs to be already built by the caller.
The involved method is public function getAuthorizationUrl($redirectUri, array $extraParameters = array()). This receives the redirect URI and builds the auth URI with the redurect URI encoded as a parameter.
So, who are the consumers/clients of getAuthorizationUrl()?
I only found one single client usage in OAuthUtils, in a line that says return $resourceOwner->getAuthorizationUrl($redirectUrl, $extraParameters); within the function public function getAuthorizationUrl(Request $request, $name, $redirectUrl = null, array $extraParameters = array())
I see that mainly this OAuthUtils is acting as an adapter between the Symfony Request and the OAuth domain model. Within this method we mainly find code to create the $redirectUri.
The cleanest solution for me would be to create a child class OAuthUtilsBehindProxy inheriting from OAuthUtils, overwriting the method getAuthorizationUrl() and having it interpret the X-FORWARDED-* headers of the request, and then have the dependency injection to autowire my class everywhere the OAuthUtils is used with the hope that noone is doing a new OAuthUtils and every user of this class is getting it passed on the constructor.
This would be clean and woul work.
But frankly it seems an overkill to me. I'm pretty sure someone before me has put an app that needs Google OAuth made with HWI behind a reverse proxy and I wonder if there's a "config option" that I'm missing or really I have to re-code all this and inject it via D.I.
So, question
How do I have HWI-OAuth bundle to behave properly when running in a docker container behind a reverse proxy in regards on how to build the "redirect route" for the google-oauth service?
Is there any way to tell either the HWI bundle or either symfony to add a "full-host" prefix IN FUNCTION of the the X-FORWARDED-* headers "if available"? This would leave the docker image "fixed" and would run in "any" environment.
The underlying reason is the way Symfony generated the full-addresses from a relative path or route name.
Here's the investigation:
The method HWI/OAuthUtils::getAuthorizationUrl() is the one that generates the OAUth auth URI and consumes the method Symfony/HttpUtils::generateUri() to get the absolute URI of the redirect_to callback that will be encoded inside the Auth URI.
The method Symfony/HttpUtils::generateUri() generates an absolute URI (that in our case will be the callback) and to do so, the method handles 3 general cases:
The parameter is already an absolute URI (the return is the parameter without further processing)
The parameter is a relative URL (the function calls the Request class to build the proto + host + port + project-path prefix to prepend to the relative URI)
The parameter is a route name (the funcion calls the Router class to build the absolute URI)
In my example I was configuring a relative URL (google: "/login/check-google") in the security.yml so HttpUtils was delegating into the Request class.
Looking at the source of the Request class we observe:
The Request class is able to use proxy headers to build the absolute class.
But for security, by default symfony does not trust that a proxy exists merely because there are X-FORWARDED-* headers in it.
Indeed it's more secure plus more flexible.
There are 2 levels of security:
Somewhere we need to tell the Request class what is the list of trusted IPs that are proxies accessing the application.
Somewhere else we need to tell the Request class what specific proxy headers are trusted and what headers are not, even it supports different standards headers (RFC headers, non-RFC apache headers, etc)
Stated here https://symfony.com/blog/fixing-the-trusted-proxies-configuration-for-symfony-3-3 is that you need to configure the trusted proxies in the front-controller by calling the static method Request::setTrustedProxies();
So adding those couple of lines in the front-controller one killing non-nee4ded headers and the other with the IP ranges of the proxies, solved the problem:
# app.php
<?php
use Symfony\Component\HttpFoundation\Request;
$loader = require __DIR__.'/../app/autoload.php';
include_once __DIR__.'/../var/bootstrap.php.cache';
$kernel = new AppKernel('prod', false);
$kernel->loadClassCache();
Request::setTrustedHeaderName( Request::HEADER_FORWARDED, null ); # <-- Kill unneeded header.
Request::setTrustedProxies( [ '192.168.104.0/24', '10.0.0.0/8' ] ); # <-- Trust any proxy that lives in any of those two private nets.
$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();
$kernel->terminate($request, $response);
With this change:
Symfony Request is able to build correct public absolute addresses from relative addresses if called thru a proxy, by deducting the host from HTTP_X_FORWARDED_HOST and HTTP_X_FORWARDED_PORT instead of HTTP_HOST and SERVER_PORT.
Symfony HttpUtils also, as it was delegating to Request.
HWI is in turn able to build a correct absolute callback redirect_to.
HWI can set the proper callback encoded inside the AuthUri.
The AuthURI that contains the proper absolute URI taking in account the proxy effect is sent to google.
Google sees the "public URI" as the one registered in the google configuration.
The workflow completes and the login process can end successfully.
In a site I'm developing I have a page that presents a post based on the variable in the url:
http://www.mywebsite.com?id=18
So this would load the post who's ID is 18 in the mySQL database.
I would like the create the same effect, but with the url being something like:
http://www.mywebsite.com/articles/title-of-article-18/
Would there be a way to create these pages on the fly with dynamic post content, where the url would originally be created by:
"http://www.mywebsite.com/articles/" + postTitle
You are looking for mod_rewrite and rewriting of urls via htaccess.
What it does is it takes patterns from your url, and the htaccess file detects the pattern redirects that to http://www.mywebsite.com?id=18. Users still see the nice url.
The directory /articles/title-of-article-18/ will not actually exist, and the user never really reaches that location because the htaccess secretly changes the url that the server processes.
See
http://en.wikipedia.org/wiki/Rewrite_engine
or a random tutorial I found:
http://www.blogstorm.co.uk/htaccess-mod_rewrite-ultimate-guide/
try url-rewriting
http://www.simple-talk.com/dotnet/asp.net/a-complete-url-rewriting-solution-for-asp.net-2.0/
I would like to display a shortened URL besides the content items on my site for ease of sharing.
What would be the most efficient way of doing so, and are there any suitable gems / libraries?
I am using rails on a mongodb/mongoid stack
should be simple enough (regardless if you are on Mongo / MySQL or anything else). what you need is a small collection (mongo if i may) that holds some kind of an MD5 hash of the real url you are after and the real url itself, for example:
ShortLink.create(:hash_link => Digest::MD5.hexdigest(resource_url(#resource)), :real_link => resource_url(#resource))
I suggest adding another route that catches those like this:
match "l/:key", "ShortLinks#show"
should be easy.
I think you can use bitly gem to shorten your URL.
The following link helps you to configure bitly:
http://www.marketingformavens.com/blog/url-shortening-bitly-ruby-on-rails
I created a sitecore year/month/day folder structure in the content tree, when i view each article under the folder node, the url could be http://local/landing/year/month/day/article1.aspx, how could I make the url like this: http://local/landing/article1.aspx?
just remove the year/month/day structure in the url.
Is there some function in sitecore like remove or hide special templates in the frontend url ?
Any help , Thanks .
You can do it in 2 ways:
Use IIS 7 Url rewrite module to change the url. This way the url will be rewritten before it gets to sitecore and you don't need to change any code. You can find more info at the iis website
You can create a custom Item resolver and add it to the RequestBegin sitecore pipeline. Alex Shyba wrote about it here.
It sounds like you may have thousands of these items, but even so, you may want to use the built in functionality of Sitecore and consider creating aliases for each of these items. Programmatically creating an the alias on an ItemSaved event or ItemCreated is probably easiest.
As #marto and #seth have said, you can use URL rewriting or aliases to solve this.
There is, however, a drawback to doing this, irrespective of how you choose to do it.
If you have very many items (your structure makes it sound like you may do) then either method will require that the URL is unique. Removing the date structure from the URL means that all items in your landing section will require unique URLs (whether inherited from their item names or by some other means). This can impact on SEO for your site, as authors may have difficulty finding an unused name that is also human readable and good for SEO. It's unlikely you want to use ugly GUIDs in your URLs.
2 options
Change Bucket configuration and the set the required folder structure, bucket configuration can be found in Sitecore.Buckets.config file
Extend GetFromRouteValue Item Resolver and overwrite the ResolveItem() method to get the bucket item.
The default GetFromRouteValue class reference can be found in Sitecore.MVC.config file and replace this with your own customized implementation.
We have implemented with customized routing and getting the exact item if the route path matches.
Thanks,
Jisha
What is the method I need to call to find the root URL for a rails application. For example, I have a site where the address is "https://host:1234/foo/app-main".
What method should I be using to get "https://host:1234/foo/images" to get the absolute url for images in the public url?
image_path(image_name)
Edit: Steve has a good point, this will only get you part of the way there. To get the rest you must be inside of a request (you probably are)
In that case though, you can combine the above with Justice's approach,
"#{request.scheme}://#{request.host_with_port}/#{request.script_name}#{image_path(image_name)}"
This question makes sense only on a per-request basis, since your one process might easily be listening on multiple domain names and on multiple schemes.
"#{request.scheme}://#{request.host_with_port}#{request.script_name}"
See Rack::Request.