Want to check current subdomain in url is valid or not. I'm able to validate if current url has subdomain or not. I want to make an api call from angular to backend with subdomain name and check if its valid. Where will be the best place in angular to do this? app.run ? some factory ?
If valid then only it should display site contents, otherwise redirect to unauthorized page. I also needs to check the current session cookies if they are valid for current subdomain. I guess I can do this by creating cookie for that subdomain only and not global domain cookie, right?
Related
The authentication process for O365 requires adding the redirect URL in a whitelist on the app’s dashboard on Azure.
However, this whitelist doesn't work with domain names. It requires to add the entire URL for every page which is not possible if you have a huge number of URLs, plus some of the URLs are dynamically generated by the backend.
Is it possible to whitelist the domain with all its sub-directories/URLs in one go?
No, it is not (unless you want to use wildcards, which you shouldn't).
In general when you need dynamic redirects,
you should store the location you want to redirect to locally in a cookie/session/local storage/session storage.
Then use a single redirect URL, and when you get the redirect there, get that stored "local redirect URL" from where you stored it, and redirect the user there.
I touched upon this on a recent article: https://joonasw.net/view/avoiding-wildcard-reply-urls-with-msal-js
I am trying to integrate my application with AAD authentication but the replyurls which i am configuring in the AAD application is
https://www.example1.com/abc/account/login.aspx
but when i am coming back after authentication i am getting redirected to
https://www.example1.com/
Only and my request is coming as authenticated but i want user to redirect to full url which i have configured.
I have tried sending RedirectUri at the time of app configuration in startup class as same as https://www.example1.com/abc/account/login.aspx that time user is redirect to this url but that time request is not getting authenticated
any one knows how i will achieve this?
thank you in advance.
Reply URL is where the token would send to . It means that it is a endpoint
which signs in users for that provider. But after signing in, the user will be redirect to the Homepage(Sign-on) URL.
For your scenario, you can change the Home page (Sign-on)URL in both AAD Application and your APP config file to the URL which you want to use.
Please refer to this documentation for detailed instructions on how to set up these configurations. Like Wayne said, you need to make sure that the home page URL is matched to whatever site you want the users to be redirected to after login. Then make sure that the reply URL and the RedirectURI are matching.
I am using laravel and AngularJS for development.
I have different portals and login page but login function is same to login all users at back end.
I want to check source URL before hitting to login function if URL is hitting from right portal to right user then it should proceed to application further other wise not.
If you wanna check the url then you can use $location provided by angular to see the url before sending the request.
I have a angular app that I needed to redirect outside to a non angular html page, so I thought I could just use the $window.location.hrefto redirect the angular app to my external site. This actually works fine, however, I have a nodejs/express backend that checks for auth token before serving up any content(even static content).
This requires a auth token to be sent in the header of the http request. Now the question:
Can/How do you add an auth token to the request that is made by changing the $window.location.href before it is sent off?
When you use $window.location.href the browser is making the HTTP request and not your JavaScript code. Therefore, you cannot add a custom header like Authorization with your token value.
You could add a cookie via JavaScript and put your auth token there. The cookies will automatically be sent from the browser. However, you will want to review the security implications of using a cookie vs. a header. Since both are accessible via JavaScript, there is no additional attack vector there. Unless you remove the cookie after the new page loads, there may be a CSRF exploit available.
This answer is NOT a safe way, as the token is exposed in the URL, which is logged in browser history, access logs, etc. Use a domain cookie instead. I'll leave the answer as it can be an easy way to debug in your local setup.
I am using JWT as authentication on a Laravel PHP backend, and it works by putting ?token=... in the URL. For example, when using AngularJS with satellizer plug-in, I add ?token=' + $auth.getToken() to the URL.
(Using CakePHP) I'm looking to setup a sub-domain for user creation, password changes and credit card information vies...as in:
secure.mydomain.com (https)
- User/Create
- User/Login
- User/UpdateCreditCardInfo
app.mydomain.com (http)
- once logged in using the "secure" site, the user will be able to access application specific views
Using the CakePHP Auth component on both my sub-domains...how do I persist the login information when the user is authenticated on "secure" then is redirected to "app" sub-domain?
See: http://book.cakephp.org/view/173/Sessions
To provide a custom configuration, set Session.save Configuration to a filename. CakePHP will use your file in the CONFIGS directory for the settings.
Configure::write('Session.save','my_session');
This will allow you to customize session handling.
// Cookie path is now '/' even if you app is within a sub
// directory on the domain
$this->path = '/';
ini_set('session.cookie_path', $this->path);
// Session cookie now persists across all subdomains
ini_set('session.cookie_domain', env('HTTP_BASE'));
That's a general problem with cookies. They're only valid within the domain they were set and its subdomains. app.example.com is not a subdomain of secure.example.com, so you can't transition cookies between them.
You can set a cookie at example.com and make it valid for all its subdomains, including app. and secure.. You can then modify the cookie on these subdomains.