I've never experienced this problem before, and it just came to our attention because a client was trying to access our page and couldn't see much of the javascript. He was navigating to http://www.mysite.com, when we've always just gone to http://mysite.com.
There appear to be no problems server-side, as in both url's are pointing to the same place. There are also no errors on the page when it loads.
Has anyone had to deal with this before?
If your absolute urls reference http://mysite.com/js/file.js and there's no redirect in place then the JS files wouldn't get picked up properly, obviously.
Are you aware of Firebug and it's net tab? You can inspect and see if the js files are being retrieved.
It would help if you provided the real link.
Are you sending the JavaScript only to authenticated users?
If that's the case, then a user that authenticated on http://example.com, will not be able to access pages on http://www.example.com assuming you didn't make any other changes. This is because the cookies set on either (www. or roo) will not be sent to the server when the user navigates to the other.
Related
Good afternoon,
I have a problem that I would like to get your help with if it were possible.
First of all I would like to mention that I am using Angular with TypeScript.
I am trying to make a kind of single sign on of several websites in a single application and I am having some problems when it comes to redirecting to the desired website.
All websites that I am trying to sign in cannot be changed and I can only make changes to the application I am developing.
On the client side, I make a request to the API (NodeJS) that performs the authentication on the intended website and returns an authentication cookie to the client.
So far so good, it's working perfectly. The problem arises when I need to open a new browser tab and pass the authentication cookie I received.
When opening a new tab I am forwarding to the page after login and I need the cookie for that task.
I tried to set the cookie in the browser to a different domain but without success.
Can someone help me, whether it is trying to find a solution or indicating a possible different way to solve the problem?
I would like to mention that the domain of all websites are different from each other and different from the application I am developing.
Thank you in advance to anyone who can help or direct me to the solution and I apologize if I did not understand perfectly what I want. Any doubts tell me that I try to explain better.
Regards,
André Pinto
From frontend you cannot set a cookie of another domain, but what you can do is to have a php page, which sets cookie of another domain or have a backend redirect. you can use this article for detailed information :-
https://subinsb.com/set-same-cookie-on-different-domains/
On reference link more :- Setting cookie for different domain from javascript
As mentioned above you won't be able to achieve this with cookies; being able to set cookies for other domains would be a massive security issue.
If you control the other website and have access to the backend, then your backend can handshake to identify the user. Otherwise you could look at using a querystring redirection to authenticate the user.
All the best.
I have, erroneously used a free site to host images, and have sent out a number of emails with this linked image in them. The URL has now disappeared and therefore all my emails show 404 for the image.
I really think that it is impossible, but is there any way to reroute this bad link to a good link? Obviously I cannot add anything to these emails. This is more about intercepting the call. If I controlled the target domain, I could probably add an A Record to reroute, but I do not.
I am just asking incase for some extreme reason there is an answer.
Thanks in advance.
unfortunately, this is not possible
because if it were, anyone would have anticipated an email call route and processed stuff in accordance.
If you can get to your old server, you can redirect your emails from there to new route but since you have lost it, I dont think this is any possibility for that anymore.
maybe contact site administration for help.
OK, so basically I've put together a very low security log in page (javascript username and passwords) which isn't a big deal cause there isn't really anything it's protecting, I just made a login page for the youth on my church website to view and study Sunday School material. What I'm wanting is to make it so you can't type in the direct html to your "profile" or bookmark it, I want them to have to use the javascript log in. For example, the script will direct bob to his "profile" at bob.html, but I want to only go to bob.html only if it comes from login.html, is there any way to do this without getting extremely complicated? I'm expecting there isn't but I thought I'd ask anyway.
If no server side programming is involved you will have to use a simple JavaScript redirection which is not even considered as a "low-level" security but as a "non-level" security :)
Anyway you can check the referrer with document.referrer and redirect to the main page when its not correct, remember that this is very easy to manipulate by the user.
More details on document.referrer can be found here http://www.w3schools.com/jsref/prop_doc_referrer.asp
if ((document.referrer).indexOf('login.html') > 0 && username=='someone' && password=='pass') {do stuff} else {user did not arrive from login.html or username is wrong or password is wrong}
If this is all from client-side javascript, then you can't do anything that's real security. I'm assuming you know that.
But, you can create a slight obstacle to direct access for the casual viewer by having the link from the login page set a very short expiration cookie (like 1-5 minutes), then go to the profile page and have the profile page have all the profile content hidden by default (via a CSS rule). Then, your javascript can check to see if the cookie is present upon loading and, if so, show the content.
If the viewer tries to go directly to the profile page, the cookie will not exist and the page content will not get shown by the javascript. Obviously, the content is still present in the page so any viewer with any knowledge of how web pages work could still see the content in other ways, but it wouldn't show by default in the browser.
Multiple schemes are possible, like the one presented above by jfriend00.
You can also use rolling URLs.
Say your profile page is at http://example.com/profile/foo. Change it to http://example.com/profile/foo?time=yyMMddhhmm where yyMMdd represents the current date, and hhmm represents the current server time. Then make sure that the server refuses to serve this page if the time doesn't match.
Easy to see what happens if someone bookmarks this link. Their bookmark will work for at most one minute.
Unfortunately, the link on the page also expires in one minute. You can solve this problem that updates the URL roughly every minute, but it is not as straightforward as it may look. You will need to take into account the fact that the time on the user's computer may be different from the server time.
Another way to do it is with a session cookie. Session cookies are good until the browser is closed. They expire automatically when you close it. This is a variant of jfriend00's original answer.
Hope this helps.
I wrote a web page that displays images from several servers on my network via simple img tags with appropriate href values. The servers require authentication before they will send the images.
It works alright, except on first load the page presents the user with a series of password prompts (one for each server). The user can select the "Remember my password" checkbox, and then subsequent refreshes of the page work without prompting, with correctly updated images. That is, until someone closes out the browser, after which a new set of prompts awaits anyone who opens the page again.
All of the credentials needed are known beforehand, and I don't care if someone could read them in the page source, since this page is in a protected part of an internal intranet site. Everyone with access to this page knows the passwords anyway.
The only browser we're allowed to use is IE 7, so I don't care about compatibility with other browsers at the moment.
Is there any way I can use JavaScript (or some other client-side code) to automatically answer those prompts so the user never sees them?
Thanks very much, in advance.
You can include the authentication in the URL:
<img src="http://paulfisher:tastybacon#internalwebs/path/to/image.png">
Where, of course, paulfisher is my username and my password is tastybacon.
No, javascript can't do this. Here are a couple of options that I've used before to solve this problem:
Change the authentication on the other servers to be either anonymous or integrated.
Proxy in the images: On the server serving the page, add another page that takes in the URL of the remote server. This new page makes a webrequest to the other server and streams the image back. The webrequest can plug in the correct credentials.
Depending on the servers' DNS names, it might be possible to share an authentication cookie across all of the servers. Then you could set up some kind of module on all of the servers to allow the shared authentication.
I have a Rails app where I set a set a session variable the moment a user lands on my site with the referer and the page they hit. Additionally, I have Google Optimizer sending traffic from my homepage to various landing pages. The problem is that I think Google Optimizer is sending users away before the cookie is set.
Is that even possible? I believe that the cookie is set from the HTTP Header, which must have fully loaded before Google's Javascript has even loaded.
Thanks,
Jason
You're absolutely correct - the explanation you propose isn't possible. Assuming the browser is loading the page from your site that sends the cookie header, it will be set, and JavaScript can't directly interfere with this.
So the problem is elsewhere - the first thing I would test is whether the Cookie header is actually being sent, whether it's being set (look in your browser's security/privacy panel), and then whether your code for checking if it's been set is functioning correctly.
As you suspected, the cookie should be sent in the header when the visitor hits your page, so google optimizer shouldnt be affecting this..
You may want to double check that you are setting the cookie, you can use firebug or similar for this (in the Net tab).