There are template witch are written by admins. And in mail there possibility to enter link (not the rails way). There is editing menu, what generates following, basic html code:
company’s profile
where user.owner_name - domain.com/user/user_name
I don't talk about localhost because it possible will not work. So I'm talking about production server.
I receive email, with broken link (if I click on it - it's not opening) but if copy link:
x-webdoc://73A3A2DC-F22E-4558-8853-C6A57985EE7C/mydomaine.com/user/
Why this appears?
EDIT
It seems it's realeted to MacOs. It prbolem appears when I view letter thorought Mail App, or Safari browser.
Now, I need any advise how to avoide this prob.
I would argue that example.com/user/user_name is not a useful URI in the context of an email, because it is missing a protocol (like: http://example.com/user/user_name). Without the protocol it could be misunderstood as a relative URL, which may lead to security issues or at least is useless in the context of an email client.
From that point of view, it is not surprising to me that some email clients or web mailers are trying to be smart and protect the user by annotating the URL in some way.
In this example the added x-webdoc: indicates that the user has to make the decision on what application to use to open that link because without a proper protocol it is not obvious what application will be able to handle the URI. See What is x-webdoc?
Related
I have a rails application and am using devise for authentication. I notice that when the email for resetting the password goes through in production then the link to reset the password breaks and it redirects to my root URL.
In development it takes me to the sign in page and a flash message appears which says that I cannot access this page without a valid token, and must provide the full URL.
while I have customized the look of the email, I am using the devise methods in order to generate the links, viz. edit_password_url(#resource, reset_password_token: #token) %>
this should ideally come up in the development environment as
http://localhost:3000/users/password/edit?reset_password_token=[GENERATED_TOKEN]
however it is coming up as follows as observed from the server logs:
http://localhost:3000/users/password/edit?reset_pass=
word_token=3DQaz7y_f63yR3MZmReUY5
on two separate lines. In production I am using sendgrid so I cannot see the url being generated by inspecting the link.
I also notice that every = sign gets converted to an =3D
Looking forward to some suggestions. Please do let me know if I must provide any more data.
I did figure out the problem, which as it turns out had nothing to do with the transfer encoding.
At the receiving end the urls do get full resolved properly in spite of the content transfer encoding.
However since I was auto generating the links, they were being generated and sent as http links. I am using a CDN that redirects all traffic over https a page rule I had added there to resolve a few issues, was causing this http link to redirect over https and eventually to the application root. This is what was causing the problem.
Generating an absolute url with https is what was required.
I am working on Asp.Net MVC 5. When i click a link (placed in another website) I navigate to UserDetails.cshtml page. Basically that 3rd party site is passing the UserName & Password to my site & using that I authorize & display further user info.
It's fine but the Url is looking like this
localhost:8080//Admin/UserDetails/UserName/PWD.
I don't want to show the UserName & Password in URL i.e URL should look something like :
localhost:8080//Admin/UserDetails/
One possible solution could be rewrite the URL in IIS (http://www.hanselman.com/blog/ASPNETMVCAndTheNewIIS7RewriteModule.aspx)
But I believe there is an easier way to handle this by using the routing mechanism of MVC.
Please help me to figure out the same.
EDIT :
As many of you are confused why I am not doing a Form Post here, let me re-frame my question. I have no control over the third party application, so I cant request them to do a form Post to my MVC application. Again the 3rd party application is a Oracle Reporting application (OBI), so doing a POST from that application might not be feasible too...
Let me reverse engineer your requirements from your question:
I want to have an URI that when invoked will give access to a secured section of my website. This URI must be clicked by visitors of a third-party site, whom I give that URI to. I want to hide the credentials from the URI.
You cannot do this, the requirements are conflicting. You cannot hand out URIs that will authenticate anyone who fires a request to that URI.
You could do something with a token (like http://your-site/auth/$token), but then still, anyone with access to that URI can use it to authenticate themselves, or simply put it up on their own website.
If you have data you want to expose to a third-party site, let that site perform an HTTP request (with tokens, usernames, headers or whatever you want to use to authenticate) in the background to your site, and display the response in their site. Then the visitor won't see that traffic, can't share the URI and all will be secure.
No. No. NO. Like seriously, NO. Any sensitive information should be sent via a post body over a secure connection (HTTPS). You can't "hide" information in a GET request, because it's all part of the URI, or the location of a particular resource. If you remove a portion, it's an entirely different location.
UPDATE
I find it extremely hard to believe that any third-party application that needs to authenticate via HTTP and isn't designed by a chimp with a typewriter, wouldn't support a secure method to do so, especially if it's an Oracle application. I'm not familiar with this particular app, but, and no offense meant here, but I would more easily believe that you've missed something in the documentation or simply haven't found the right way to do it yet before I'd believe you have to send clear-text credentials over GET.
Regardless, as I said previously, there's no way to hide information in a GET request. All data in a GET is part of the URL, and therefore is plainly visible in the browser location bar or whatever. Unfortunately, I have no advice for you other than to look closer at the documentation, even reach out to Oracle if you have to. Whether by post or something like OAuth, there almost has to be another way.
This question pertains to the Visual Studio generated code that you get when you open an ASP.NET MVC application in Visual Studio Community 2015 RC.
In this generated code, what is the purpose of the actions SendCode and VerifyCode on the AccountController?
I have read their code but the time investment it requires to read this code and look up the meaning of the functions called within these from the MSDN -- all of which I have done -- and then open their views to see what they do, and then look for references of where they're called -- is too much for the benefit. Microsoft left so many comments in this generated code elsewhere. They could have left a few comments explaining the workflow of these actions and told us where they're meant to be (and are currently) called from.
One big reason for confusion is: these actions aren't called or redirected to from anywhere else.
Anyway, my understanding is that they're there to ask a visitor who has just registered on the website with his email address, to verify his email address by requesting that he be sent a code.
But then in the source code for the SendCode action, there's this drop-down in the code that gets the registered two-factor authentication providers in the View (which I have only seen by reading the code. I haven't been able to run this action because it isn't called from anywhere and I don't know how to get to it with the right arguments).
This leads me to suspect that this has to do with two-factor authentication by email and/or phone.
But two-factor authentication by phone is already covered in the ManageController.AddPhone action and the ManagerController.EnableTwoFactorAuthentication, right?
It seems like one needs an old priest and a young priest to understand what's in the generated code.
Could someone please tell me what these two actions are for and where are they (supposed to be) called from? What's the entire workflow for these two actions?
I believe these methods are in place if you wish to implement signup validation logic. For example, a user signs up to your website and you require them to validate their information (usually email address) before approving their signup.
So the flow would be:
User signs up
System creates user but doesn't activate account yet
System sends email to user email with validation link (AccountController.SendCode())
User opens email
User clicks validation link which navigates to validation page on your website
Page validates user information (AccountController.CheckCode())
If validation is successful, account is activated
If validation is not successful, error message is displayed
I'm not sure if you've seen this post already but it outlines how you can implement something similar using SendGrid as your email provider.
the purpose of sendcode and verifycode is in case you want to leverage MFA (multi factor authentication). hence, after login, you would be redirected to send code where you decide whether to send a code via i.e. mobile or email and once the code is sent, you get to verify code to enter the code you requested to complete the process.
I'm working on a project that uses sessions to manage the currently logged in user with a slight twist, there is no log in form on the actual application. Instead, another site will provide a button that should log in the user and redirect to their profile page.
For example, the customer is viewing their profile on Site A, the 3rd party application. From their profile on Site A they click on a button that should log them in to Site B and redirect to their profile on Site B, the site I'm building.
I'm a unfamiliar with the security concerns for a case like this. My initial thought is that if Site A POSTs via https the user's email address and password, then it should work just as if they were filling the form out on my site, Site B.
What security concerns am I missing here or will this just not work at all?
NOTE: The 3rd party site is basically out of my hands and I'll never convince that team to setup any sort of OAuth protocol, or at the very least its going to take unacceptably long. Plus, OAuth, at least with my understanding is method to accept requests from any number of 3rd parties. No other site except for SiteA will ever attempt to log people in.
This sounds like a typical application for an OAuth provider.
Get an overview and grasp the concept here: http://en.wikipedia.org/wiki/Oauth
There already exists OAuth Providers in Ruby, so you don't have to do everything by yourself: e.g. https://github.com/songkick/oauth2-provider.
But if you really wanna do this without, then I would let the other server generate a hash containing the users id (can be username, email, or database id), a random token, the current timestamp and then sign this using MessageVerifier. Then you can check on your server if the timestamp is within a certain range (some minutes) and if the message verifies (using the same key naturally). If so, then accept the user.
If the other site uses PHP, then you might have to rebuild the generate method in PHP. Find the source in Ruby here.
I'm trying to setup a "private beta" for a site that I'm working on. The site uses open id. I don't want anyone to even browse the pages if they aren't part of the beta. What's the best way to implement this? Any suggestions?
For example:
When the site goes live, users will go to http://www.mydomain.com which will not require them to log in.
For the beta I want to restrict access. Users that go to http://www.mydomain.com will be redirected to a login page. Anyone attempting to access ANY PART OF THE SITE who is not authenticated will be redirected back to the login page.
I could stick [Authorize] attributes all over my controller actions, but that seems stupid.
If you're using ASP.NET MVC, it comes with authentication/authorization out of the box. You should be able to use that to setup authentication on your site.
Alternatively you could setup app server settings - IIS lets you setup username/password on a specific site it's serving, regardless of what the actual application may do. If you have access to the app server this might be the best solution.
If you're using IIS6, you can setup authorization easily. Right-click on your site > Properties > Directory Security Tab > Authentication and Access Control > Edit, and enter a username/pwd of your choice. Done.
The real question is how are they being invited to the private beta?
You could setup a password which drops a cookie much like serverfault.com does.
OR
If you know who you are inviting: you could add them to the system before hand using the email/login information that you already know about them (assuming you are inviting them via email)
I have implemented a function in a web application a while ago where we go the possibility to block access to the full website unless the user was an administrator (which in our case meant that the user account was a member of a specific group in Active Directory).
It was based on two things. First, all pages in the web application inherited not directly from the Page class, but from a custom page class in our web application. Second, we had a value like this in the appSettings section of web.config file:
<add key="adminaccessonly" value="0" />
The custom page class would check that value when loading. If it was not 0 it would redirect to a page (that did not inherit the same custom page class, though) informing the user that "the site is not available right now". If the value was 0 the page would load as usual.
In that application we used this to be able to take the site "offline" when we deployed a new version, giving us some time to verify that all was good before we let in the users again.
Best way are invitation system (based on invitation code) or manually confirmation access after create profile in your system. imho
Or you could host the site on a private server, and set up a VPN to use it. Depending on your resources and needs this may be the easiest and most secure way to do what you want without modifying your codebase.
OR alternatively you could use Apache or IIS to force authentication on access to the website directory. Keeping the authentication info in .htaccess for a while.
Even though you use open id authentication, you may still need some form of authorization mechanism. The simplest form would be a user-roles system in your database that assigns different roles to users
In your case, just assign the private_beta role to your private beta invitees and ensure you your authorization mechanism that all users have private_beta privilege before they may continue.
If you don't want to provide authorization for the public site (where everyone can do everything, once authenticated), then, you may only need to do a quick-and-dirty post-processing (for private beta only) on your open_id authenticated users to check them off a short list (which you can store on a text file.