This is what I need to do:
I'm creating a site in CakePHP where I need to show different stuff (logo, pictures, etc) depending on what sub-domain the user has used to get to my site. For example: let's say there are 3 sub-domains:
subdomain1.mydomain.com
subdomain2.mydomain.com
subdomain3.mydomain.com
All three sub-domains will point to the same folder in the server where my CakePHP app is. I would like to know how can I get the sub-domain used by the user so I can show different things depending on that.
I don't know if this can affect my question, but there's one more thing. The users won't actually use the sub-domain links. They will use other domains that redirect to the sud-domains. For example, a user will enter www.whateverdomain1.com and he will be redirected to subdomain1.mydomain.com. However, I've been told that the user won't actually see the redirection, he will always see the www.whateversomain1.com that he used.
Any ideas? Thanks so much in advance!
The easiest way I can think would be to have your webserver redirect requests from sub.domain.com to domain.com/sub, and from there using the route configuration.
In the route configuration - you have two options, either to use prefixes (http://book.cakephp.org/view/945/Routes-Configuration#Prefix-Routing-950) or setting up named parameters:
Router::connect(':subdomain/:controller/:action/:id', array('id' => '[0-9]+'));
And in your controllers you can then check via
$this->params
to see what the subdomain is and set your variables accordingly.
Related
I'm seeing something weird that I've not run across before. I've got a web app and I redirect in that web app to Azure AD to get a code that I can exchange for an access token. I've done this many times before so I'm just reusing the same code. I've created my app registration in Azure, just as I've done many times before. The problem is this - normally I can just put a host name for a Reply Url in the app configuration and then Azure AD is fine redirecting anywhere to that host.
For example, if I want to redirect to https://foo/users/processcode, I can normally just put a ReplyUrl of https://foo and it all works fine. In this one case, it says "'https://foo/users/processcode' does not match the reply addresses configured for the application blah". If I put in the fully qualified path for the ReplyUrl then it works, but for a variety of reasons that are beyond the scope here I don't want to do that.
So I'm not following why it might have a problem in this case. Wondering if anyone has seen or knows why this might be an issue all of the sudden.
Thanks.
The Redirect URL/ Reply URL has to match the exact page you want to be redirected to. You can add multiple redirect URLs to your application registration information if you want to redirect to different pages in your web site - or your web page could make the redirection for you.
Another option is to add a * in a redirect url as well (https://mywebsite.com/*) - but this only works with non-converged applications.
I need to put a link into email. When user clicks on it, angularjs app should open specific page and entity. I suppose that the link should contain id of the entity. This allows to find the record on backend side and then open page.
Is it safe to publish such a link in email(I mean id of the record in DB)? Do we need to hash id?
I don't really see much trouble.
There are a lot of web pages (angular or not) which provides direct links to pages using the entity id as parameter.
In the case of angular, when another - non-authorized - user tries to enter, it will ask the backend, the backend with reject its petition and you can redirect the user to the home page. So if some user tries to access that route, he well just see the home page.
It is also true that in general (I mean, not angular specifically) some people likes to hash the id, but I don't see that as really needed.
So it comes down to the use case / personal preference. From the point of security, your backend won't give any entity even if you know every piece of it. You need to be logged in AND able to retrieve it.
I have two different CakePHP based applications on same server. They are placed in separated directories, and each of them use it's own database. Also, they both have implemented authentication. So, (in my opinion) they are fully independent.
Problem I have is that I cannot be logged-in in same time in both applications (in same browser).
Can you help me what I'm doing wrong in this case, and how can I be authenticated in both of them sametime?
Try to change Session.save variable in app/config/core.php. Default is 'php', so change it to 'cake'. This will make Cakephp store the Session variables in the app/tmp/sessions directory. Remember to give write permissions to this folder. Also make shure that both apps have diffrent Security.salt key in the same config file.
So I'm just starting to play with CakePHP and was wondering if the following was possible:
A single install of Cake, with a super admin login. Then, admins that have access to specified "sub sites", and the ability to create/edit content and users on those sub sites. Finally, the ability to map domain names (not subdomains, but unique domains) to the routes; so instead of mysite.com/subsite/posts/1 it would just be newdomain.com/posts/1
Essentially, I'm looking to replicate the experience of using Wordpress Multi-user (with domain mapping).
Is this possible? If so, what should I be looking into?
Sure. You can even use the same set of code and just configure certain domains to point to the code. Then in the code base, tie a domain ID to each user and the content so it knows where it belongs. You can have admin users belong to all domains. Then when you add regular users, you can specify what domain they belong to.
You could establish the domain checking in the Config/bootstrap.php and then set the configuration for the domain like so:
Configure::write('domain_id', 'someDomainSpecificID');
Then you only have to maintain one set of code and one database from many domains.
If the domains have to be physically separate, you could set up one location for the ADMIN users (single database) and run everything against that.
There are many ways you could architect it, it just depends on what your specific needs are. It sounds like a cool project though.
I am working on a chrome bookmarking extension with google app engine as the backend. I am the only user now but I thought that if in the future there are other users the url needs to include the user name for the extension to interact with the backend. So I was thinking to change
http://ting-1.appspot.com/useradminpage
to
http://ting-1.appspot.com/user_name/useradminpage
where "user_name" is the gmail user id.
But I looked at twitter url and I see that they have
http://twitter.com/#!/user_name/
What is the purpose of "#!"? Is my scheme good enough in this case?
The # in a URL signifies the 'fragment identifier'. Historically this has been used to identify a part of a document identified by an 'anchor' tag, but recently webapp developers have begun to use it to pass information about the page state to Javascript code running in the page. This is used because it's possible for Javascript code to modify the fragment of the current page without causing the page to reload - meaning it can update as you browse through the webapp, and go right back to where you were when you reload the page.
The fragment is not sent to the server when the browser loads a page, so Twitter's server just sees a request for twitter.com; it's up to the Javascript code in the page to examine the fragment and determine what to do after that.
In your particular case, assuming you're using the App Engine User service to authenticate users, you have a number of options for how to distinguish users in your URLs:
Use their email address. In theory this can change, and users may not want their address in a URL they will share. If the URLs are private, this is more or less a moot point.
Use their user_id. This is opaque and reveals no useful information about the user, so it's safe, but it's also meaningless and hard to remember.
Let users pick a nickname for their URLs, like Facebook and other services do, on a first-in, first-served basis.