multiple clients under single domain typo3 - typo3

im trying to configure realurl to work with multiple clients but under a single domain and a single page tree
[root]
client 1
page1
page2
client 2
page 1
page 2
all clients have 'is Root page ' checked
they a have a template which is rootlevel
if they were different domains or at least subdomains then i would just create a Domain record in each of the root pages and forget about it but i cant instead i got this structure
domain.com/client1/page1
currently realurl is configured to automatically
im basically looking for a way to identify the clients
im getting this error when trying to access a client domain.com/client1/
The page did not exist or was inaccessible. Reason: Segment "client1"
was not a keyword for a postVarSet as expected on page with id=84.
id=84 is a root page with a Domain record that matches the domain in the url
update 1
i changed my structure to
[root]
generic client
client 1
page1
page2
client 2
page1
page2
and removed 'Use as root page' along with the Domain Records from the clients
sometimes i over-complicate things for no reason :P

maybe you will find here your solution..
https://github.com/Ecodev/bootstrap_package/blob/master/htdocs/typo3conf/RealUrl.php

Related

AEM - visiting restricted page via dispatcher redirects to publisher login page

I'm a DevOps engineer who has inherited an AEM 6.5 environment from an AEM developer who is no longer with the organization. The architecture consists of one dispatcher instance, one author instance, and one publisher instance. Currently the dispatcher is configured to fetch and cache content from the publisher instance and serve content to users from the cache.
It works for all pages except login pages when the user attempts to visit a restricted page (any page which require the user to log in). When visiting a restricted page via the dispatcher instance (https://example.com/site/restricted.html) it performs a 302 redirect to the login page on the publisher instance (https://publish.example.com/site/login.html). This is the same behavior which occurs if a user visits the restricted page directly on the publisher instance (https://publish.example.com/site/restricted.html), but it is not the desired behavior for when accessing the site via the dispatcher instance.
I am trying to make it so that when visiting restricted pages through the dispatcher instance that the user is brought to the login page through the dispatcher (https://example.com/site/login.html), not redirected to the publisher instance. The user should not see publish appear in the URL at any time, nor should the existence of the publisher instance ever be made visible to a site visitor.
I've been unable to find where this redirect is defined/configured. Here is a summary of my research so far:
I have reviewed all Apache configuration on the dispatcher instance in httpd.conf and all conf.d files and there are no rewrite rules or redirects which seem to cause this behavior. There are no references to the publisher instance IP address, hostname, URL, or subdomain in any of the conf files or VirtualHost blocks.
I have reviewed all dispatcher configuration in the mod_dispatcher.so module's dispatcher.conf config file on the dispatcher instance and there doesn't seem to be anything related there either. The only reference to the publisher instance is in the /farms/renders block in dispatcher.any.
I’ve examined every configuration option listed in both the author and publisher instance configuration web consoles (https://publish.example.com/system/console/configMgr) which include any of these terms: login, redirect, restricted, authorization, and authentication but could not find anything that seemed relevant.
I’ve also searched in CRXDE Lite on both author and publish (https://publish.example.com/crx/de/index.jsp) for the same terms but didn't find anything relevant. I found the login.html page and it's child node jcr:content component but there's nothing about redirects in the properties.
I've gone onto the publisher server instance and checked the contents of /opt/aem/crx-quickstart/conf. I see bundles.json, cq.pid, quickstart.properties, and sling.properties but none of them have any clues.
I've found a file at /opt/aem/crx-quickstart/launchpad/config/com/day/cq/auth/impl/LoginSelectorHandler.config which contains this:
:org.apache.felix.configadmin.revision:=L"1"
auth.loginselector.defaultloginpage="/libs/granite/core/content/login"
auth.loginselector.mappings=[ \
"/libs/granite/core/content/login:/login", \
]
but I'm not sure what that is referencing. There is no /libs/granite/core/content directory on the server.
Where else might this redirect behavior be defined?
Also check, in /system/console/configMgr for Apache Sling Resource Resolver Factory and the Day CQ Link Externalizer for possible mappings defined there as well.

How facebook like websites is able to load the profile, instead of a directory when a request like facebook.com/profile/username is recieved?

When the facebook.com/profile/{username} is requested how is server able to load page with data corresponding to that user, instead of navigating to a directory named in that {username}, and possibly showing a 404 error ?
It's achieved typically using a pattern called "front controller", where all requests are handled by the same file (let's say index.php, talking specifically about PHP now). So all URLs are like this:
facebook.com/index.php/profile/abc
facebook.com/index.php/account
That file serves as the bootstrap for the application, reading extra parameters (anything after index.php) and dispatching requests to the appropriate handlers/controllers.
Then there's multiple ways you can get rid of that ugly index.php, depending on how you configure your web server (loads of questions here about that subject: htaccess remove index.php from url as an example).
Read more about it here: https://en.m.wikipedia.org/wiki/Front_controller

ember-simple-auth: Error: Assertion Failed: The route index was not found

I am building an app with the use of ember-simple-auth.
So it looks very much like the library its doing is thing.
Here is what happens:
user tries to access /dashboard but is redirected to /
the route / contains the login form
the user logs in with valid credentials
Server responds: /token 200 0.252 ms - 52
But an error message is shown: Error: Assertion Failed: The route index was not found
user navigates to /dashboard and can now see the content, navigate around protected areas, and successfully log out.
My question is, how do I define /dashboard as the route instead of index? So that after successful login you are redirected to /dashboard
You can configure Ember Simple Auth's routeAfterAuthentication in the config, e.g.
ENV['ember-simple-auth'] = {
routeAfterAuthentication: 'dashboard'
}
4 years later...
On Ember Simple Auth Part, you can add routeAfterAuthentication and call it a day, because of ESA default to index.
If we dig deeper, as far as why ESA was and still defaults to the Index route, is that Ember always generates 2 routes for you:
one "" for ApplicationRoute
and "/" for IndexRoute,
You get these 2 routes for free.
I found 3.20 version doc's wording is verbose, so I'm pasting from 1.10 doc, but the idea remains the same
On that perspective, ESA uses IndexRoute as default is a safe bet.

TYPO3 extension real_url returns 404 on all pages

assume the following pagetree structure
root
client1
page 1
page 2
page 3
client2
page 1
page 2
page 3
by default TYPO3 will display the page by id /index.php?id=[pid]
I'm trying to achieve the following effect
/client1/page1
so I came across the realurl extension which I did managed to make it work and I got the expected result in the url after setting
config.absRefPrefix = client1/
in my setup.ts field in my template
realurl.basic.enableAutoConf = 1
in the extension's configuration page
but now I'm getting a 404 on all pages when I access them like this /client1/page1 and
I only get the content without any css images and javascript when I access them over id
because the absRefPrefix is now added to the resources
e.g. /client1/fileadmin/assets/images/logo.jpg
whats wrong with this picture?
update 1:
setting absRefPrefix = / did 'fix' everything everything however I'm not meeting the client requirement now
the client's name should be in the URL in this format
mysite.com/client1/page1
right now I see mysite.com/page1
the client name is being skipped that was reason I added the client name in the absRefPrefix
Just like "user" i have to ask... why not place everything under root?
Then use:
config.absRefPrefix = /
config.simulateStaticDocuments = 0
config.tx_realurl_enable = 1
Answer to update1:
Check the pages Client1 and Client2, in page properties, general tab: Exclude from speaking URL should be left unchecked. RealUrl should by default create the structure you are looking for if the rootpage holds the domain and the client pages are really pages and not different websites.

Unable to change the default CQ login page

I would to change the default login page (to /content/ethz_ch/Login)
I configured tha page by the Day CQ Login Selector Authentication Handler
In ./launchpad/config/com/day/cq/auth/impl/LoginSelectorHandler.config I see
auth.loginselector.defaultloginpage="/content/ethz_ch/Login"
as expected.
I then configured a test page (/content/ethz_ch/de/auth_test.html) with a closed user group and left the login page field blank.
When accessing the test page, instead on the newly defined login page I am redirected to
https://..../system/sling/cqform/defaultlogin.html?resource=%2Fcontent%2Fethz_ch%2Fde%2Fauth_test.html&$$login$$=%24%24login%24%24
Any idea on what I am doing wrong?
In the Day CQ Login Selector Authentication Handler there is a Path Info setting which restricts the possible login pages:
A list of request extensions indicating requests for which the Login Selector Authentication Handler may request credentials. Any request whose extension is not one the listed extensions will not cause the credentials to be requested. If this list is empty the default list of html and htm is used. Note that the list entries must not have leading dots. Requests without extension or requests with trailing slashes (/) are always handled by the Login Selector Authentication Handler regardless of this configuration.
Specifying the Default Login Page with the full URL (with extension) solved the problem:
/content/ethz_ch/login.html